gpgme android build fails looking for /usr/local/lib/libgpg-error.la

[Marcus Brinkmann]

On 03/10/2012 12:44 AM, Hans-Christoph Steiner wrote:
>
> On Mar 9, 2012, at 2:04 PM, Hans-Christoph Steiner wrote:
>
>>
>> On Mar 9, 2012, at 1:23 PM, Marcus Brinkmann wrote:
>>
>>> On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote:
>>>>
>>>> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not.  I tried to trace it a bit, but no luck yet.  Any ideas where this is being set?
>>>>
>>>> To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc.
>>>> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile
>>>
>>> It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line.
>>>
>>> That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error.
>>>
>>> I made a pull request on github (first time for me):
>>>
>>> https://github.com/guardianproject/gnupg-for-android/pull/2
>>
>> Awesome, thank you!  I merged it and am running a whole new build now.
>
> Here's the next step:
>
> - could you update config.sub and config.guess to the latest version?  That's required for Android support, i.e. the host arm-linux-androidabi, otherwise ./configure dies like this:
>
>    checking host system type... Invalid configuration `arm-linux-androideabi':
>      system `androideabi' not recognized
>    configure: error: /bin/bash ./config.sub arm-linux-androideabi failed

Fixed in gpgme ced1ad01aed32d1e4c5000f3b901db018ef7bf1e

> - I needed to apply the attached simple patch to get things building since Android does not have SYS_gettid but does define __linux.  It seems to be something in _GNU_SOURCE, so __gnu_linux__ seems an appropriate test.

Or we just use __NR_gettid, which should work everywhere.
Fixed in gpgme ff0a640a18e7b7457e6c2edfdc8307bf44628b60

> - the *-config scripts don't seem to work when cross-compiling, since they use prefix= but they don't include DESTDIR, i.e. they assume that the libs are all installed into their final destination.  Or am I missing something?  I'm using ./configure --with-gpg-error-prefix=$(LOCAL) ($LOCAL is the full path, not just the prefix) but that doesn't seem to help because I get:
>
> /bin/sed: can't read /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such file or directory
> libtool: link: `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not a valid libtool archive
>
> I've also tried using sed to replace the prefix= line in each *-config script to the full path, and it also gives a similar error.  But I found that merely running "make -C gpgme" works...

The way this is supposed to work is this:

At configure time, --prefix= should be used with the actual path where 
the files will be found at the time you compile the next package.

make DESTDIR is for installing into a staging area for packaging.  The 
files will not be usable until they are relocated to the actual prefix.

For a cross-build, things are confused a bit, of course, as you want to 
access the files in two locations, one path for the build system and one 
for the host.  Oh well.  For Windows builds, we prefer the cross 
environment and do the runtime lookup dynamically in cooperation with 
the installer.  For non-Windows systems, the other way around may be 
more convenient.  But then, you might have to do some work anyway to 
make sure files are found in the android filesystem, which probably is 
different from a normal Unix install.

So I'd say try the approach to set the cross build locations with 
configure --prefix option, which is the least amount of hassle at build 
time, and then patch things up for the android host install later, by 
using configure options such as gpgme's --with-gpg or if necessary, 
adjusting the code that locates various bits of the system in gpgme and 
gpg (gpg-conf in particular).  It depends on the packaging and how the 
android filesystem works.

I might have a look at your build scripts and suggest something more 
specific, but maybe you have already thought about how the android 
packaging etc will work and can share some thoughts on that?

Thanks,
Marcus