changing SONAME for libs on Android

[Hans-Christoph Steiner]

On 06/26/2013 11:15 AM, Hans of Guardian wrote:
> 
> On Jun 25, 2013, at 3:39 AM, Werner Koch wrote:
> 
>> On Tue, 25 Jun 2013 01:04, hans at guardianproject.info said:
>>
>>> Right now, when building the GnuPG suite for Android, it creates
>>> shared library files that are named in the normal GNU/Linux style,
>>> i.e. libfoo.so.1.0.3, including the ABI version after .so.  When
>>> building for Android, it currently inherits this behavior, perhaps
>>> because they share the Linux kernel.  But unfortunately, this is not
>>
>> The reason is that libtool selects this versioning scheme.  It is based
>> on the several factors but mainly on the cpu-vendor-os triplet.
>>
>>> So I'm curious whether this would take a lot of work to do, and what
>>> other repercussions such a change would have.  As far as just changing
>>
>> Because we are using libtool, this may only be fixed in libtool.  A
>> quick check of the current libtool (2.4.2) does not reveal any strings
>> "android" or "bionic" thus I assume there is no special code for android
>> there.  Autoconf however knows about Android (see config.sub).
>>
>>> the SONAME in the build process, that should be pretty
>>> straightforward.
>>
>> I don't exactly understand the problem.  Is it merely that ld.so does
>> not follow symlinks or is ld.so very different from the glibc ld.so ?
>>
>> For the former it should be easy to change the name after installation.
>> For the latter we also need to change libtool because it takes care of
>> installing the libraries.
> 
> The linker in Android is very different, its very stripped down and basic.  It only looks in LD_LIBRARY_PATH for paths, it has no hard-coded default lib path and it entirely ignores rpath in a binary.  My guess is that it does follow symlinks. 
> 
> The Android APK installer handles installing the .so files, and they are installed in a way that only root has access to that folder.  That means even the app itself cannot modify them or add symlinks.  We have worked around this by entirely managing the installation of the .so files in the app, then setting LD_LIBRARY_PATH.  But this is a approach that is fraught with difficulties and complexity.
> 
>> A quick search found these notes on a gstreamer presentation slide:
>>
>>  - android's dynamic linker has a hard-coded limit on the number of .so
>>    files (shared libraries and/or plugins) you can load in a single
>>    process.
>>
>>  - Android's linker is limited to 64, 96 and 128 shared libraries
>>    Including all plugins we have 262 shared libraries
> 
> Currently, we are only using about 10 .so files for the app.  I guess I'm not aware of all the plugins for GnuPG.
> 
> 
>> May be it it worth to look closer at this.  I consider it important to
>> know the exact reason why there are problems with the SO files before we
>> start hacking on libtool.
>>
>> The next version of libtool has major changes and is not anymore a
>> complex shell script.  I assume it will take more than a year before a
>> new libtool version is released.  For that reason, small changes to the
>> included 2.42 version of libtool are justified (in fact I recently did
>> this for W64 and def file parsing).
> 
> Sounds like modifying libtool is the way to do it, and also working to get this stuff incorporated upstream.
> 
> .hc

Luckily someone from Google already beat me to it, so his commit just needs to
be included:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=8eeeb00daef8c4f720c9b79a0cdb89225d9909b6

This only changes m4/libtool.m4, which is currently included in this projects:

gpgme/m4/libtool.m4
libassuan/m4/libtool.m4
libgcrypt/m4/libtool.m4
libgpg-error/m4/libtool.m4
libksba/m4/libtool.m4
npth/m4/libtool.m4

It seems to me that gnupg will also need this patch, I'm not sure how that
works, since there is no gnupg/m4/libtool.m4 to patch.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81