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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: gpgme android build fails looking for /usr/local/lib/libgpg-error.la
From:       Hans-Christoph Steiner <hans () at ! or ! at>
Date:       2012-03-12 16:18:48
Message-ID: F742BCDD-C652-42B2-914F-810BB9028F01 () at ! or ! at
[Download RAW message or body]

On Mar 12, 2012, at 11:52 AM, Marcus Brinkmann wrote:

> 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?

Android's linker doesn't use rpath at all, so I think this is going to look more like \
the Windows setup you describe.  The libraries are all installed on the phone to \
/data/data/info.guardianproject.gpg/app_opt/lib and that path is added to \
LD_LIBRARY_PATH in the environment where gpg2, gpg-agent, and dirmngr are run.

So I guess I should change all the --prefix settings to be the cross-build install \
location, then use the --with-gpg, etc. options to set where the executables will be \
found on the phone.

.hc

----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own government." - \
Martin Luther King, Jr.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[prev in list] [next in list] [prev in thread] [next in thread] 