Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Hi Bruno,

Bruno Haible wrote:
> Roumen Petrov wrote:
> > Android and Microsoft windows must not encode any paths.
>
> You probably mean to say: Shared libraries packaged in Android .apk
> files are mentioned in the Android manifest file (elements <uses-library>
> and <uses-native-library>) [1] and therefore don't need a RUNPATH.
>
> But shared libraries created in the Termux environment are a different
> case, and they do need a RUNPATH, as I explained in the previous mail.

RUNPATH or another section.
So far so good but not all loaders support all features elf format.
You cannot use one particular sample to dictate for all others.

On top of this run-paths are again rules on some above mentioned OS-es.
On those operation system shared libraries could be installed anywhere.


> > When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries 
> > and executable could run in any Android profile.
> > The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus".
> > PKIX-SSH binaries use ldns as resolver library. This library uses libtool.
>
> Again: If you want a certain binary that you build to have no RUNPATH, use the
> Android SDK, not Termux and not libtool. Or use libtool outside of Termux
> and don't provide a -R option.

There is nothing related to the way how binaries are created by high level 
build environment.
You cannot dictated how to build binaries. I use standard build provided by 
project.

This is reason do not understand you point here. You environment is with 
"hard-coded" paths. I mean at least prefix.

I cannot understand why you build does not use -Xlinker (please check libtool 
documentation for exact name) to specify run-time paths.
You environment is specific and does not fulfill Android requirements.

Libtool is general purpose build system and so must follow OS-requirement.
General build system cannot follow wish list of a developer in environment with 
hard-coded locations.
This is reason Termux application to fail to run in other Android profile.

Termux is a good sample for broken Android application.
Libtool must not follow builds in environment broken by design.


> > Also to ensure that binaries runs on support API levels elf-cleaner is should be run to 
> > "strip" certain sections.
>
> You mean [2] or [3]? I think this is out of scope for libtool, because:
>    - As far as I understand, it applies to both shared libraries and
>      executables, and since executables can be created without using libtool,
>      the right place to invoke these tools are not in libtool.
>    - As you say, it depends on the minimum supported Android API level, which
>      is a priori known to the Makefile and to the compiler (via '-target'
>      options), but not known to libtool.

Related to functionality supported by Android loader.
If you would like to distribute binaries clean of some section is strongly 
recommended.

But if build is for fun please pass to the linker specific paths.
As pointed above you environment is with hard-coded location i.e., it is easy 
to set linker options.

> Bruno

Roumen