changing SONAME for libs on Android

Werner Koch wk at
Tue Jun 25 09:39:00 CEST 2013

On Tue, 25 Jun 2013 01:04, hans at 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., 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 does
not follow symlinks or is very different from the glibc ?

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.

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

  - Android's linker is limited to 64, 96 and 128 shared libraries
    Including all plugins we have 262 shared libraries

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).



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list