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

[Roumen Petrov]

На 17.04.24 г. в 18:29 ч., Ileana Dumitrescu написа:

Follow-up Comment #3, patch #10393 (group libtool):

Thank you for the suggestion. Since we are already embedding rpath into
Android, 


And this is now critical defect - https://savannah.gnu.org/support/?111011


we could take the next step and start using GNU/Linux versioning.


No!

Android loader is not compatible.

Roumen

[patch #10393] Fix shared library support on Android

[Ileana Dumitrescu]

Follow-up Comment #3, patch #10393 (group libtool):

Thank you for the suggestion. Since we are already embedding rpath into
Android, we could take the next step and start using GNU/Linux versioning.

This would be contrary to the standard method of Android versioning, in which
shared libraries are not versioned. Although this could be overwritten by
users if needed. There are probably more people on Android using Libtool with
the GNU linker than with the Android linker. I assume most people using the
Android linker are also using the Android SDK. I really have no insight into
this however, so corrections (and solutions) are welcome. :)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[patch #10393] Fix shared library support on Android

[Arun]

Follow-up Comment #2, patch #10393 (group libtool):

I have a suggestion. If we try to build a library that already exist in
_/system/lib/_ or _/system/lib64_ there may be conflicts. So I think setting
version_type to _linux_ and adding _$major_ as suffix to soname_spec will be a
good idea.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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 
and ) [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

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

[Bruno Haible]

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

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

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

Bruno

[1] https://developer.android.com/guide/topics/manifest/manifest-intro
[2] https://github.com/kost/android-elf-cleaner
[3] https://github.com/termux/termux-elf-cleaner

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

[Roumen Petrov]

Bruno Haible wrote:

Roumen Petrov wrote:

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Why do you mention Microsoft Windows? The commit 
47c71f61df9ace4956cc943f291480315174726b
has no effect on Microsoft Windows.


When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!


Why do you want that executables never have RUNPATH on Android? Just saying
"NO! NO! NO!" is not a justification, and your arguments in [2] were not
sensible either.

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. It's that easy.
[SNIP]


Android and Microsoft windows must not encode any paths.
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.

Also to ensure that binaries runs on support API levels elf-cleaner is should be run to 
"strip" certain sections.


Roumen

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

[Bruno Haible]

Roumen Petrov wrote:
> Android and Microsoft windows libraries must not use hard coded paths! 
> Nevertheless what is supported by linker or loader.

Why do you mention Microsoft Windows? The commit 
47c71f61df9ace4956cc943f291480315174726b
has no effect on Microsoft Windows.

> When I read commit I agree that is correct do not have RUNPATH!
> The problem is that commit message is not so clear. Actually commit uses 
> rpath flag!
> NO! NO! NO!

Why do you want that executables never have RUNPATH on Android? Just saying
"NO! NO! NO!" is not a justification, and your arguments in [2] were not
sensible either.

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. It's that easy.

The problem I was encountering, as described in [1], is in the Termux
environment, which uses absolute file names everywhere. In this environment,
the use of RUNPATH is mandatory. Without RUNPATH no executable that uses
a shared library would run. That's why the Termux people added a RUNPATH
value:

$ readelf -d /data/data/com.termux/files/usr/bin/cp | grep '\(RUNPATH\|NEEDED\)'
 0x001d (RUNPATH)Library runpath: 
[/data/data/com.termux/files/usr/lib]
 0x0001 (NEEDED) Shared library: [libandroid-support.so]
 0x0001 (NEEDED) Shared library: [libgmp.so]
 0x0001 (NEEDED) Shared library: [libiconv.so]
 0x0001 (NEEDED) Shared library: [libc.so]

$ readelf -d /data/data/com.termux/files/usr/bin/emacs | grep 
'\(RUNPATH\|NEEDED\)'
 0x001d (RUNPATH)Library runpath: 
[/data/data/com.termux/files/usr/lib]
 0x0001 (NEEDED) Shared library: [libxml2.so]
 0x0001 (NEEDED) Shared library: [libncursesw.so.6]
 0x0001 (NEEDED) Shared library: [libgnutls.so]
 0x0001 (NEEDED) Shared library: [libm.so]
 0x0001 (NEEDED) Shared library: [libz.so.1]
 0x0001 (NEEDED) Shared library: [libdl.so]
 0x0001 (NEEDED) Shared library: [libjansson.so]
 0x0001 (NEEDED) Shared library: [libgmp.so]
 0x0001 (NEEDED) Shared library: [libc.so]

The main remaining problem was that if a Termux user configures a
package with a non-default --prefix and that package installs a shared
library, the Termux-provided RUNPATH is insufficient: The program
would always only see the Termux-provided shared libraries. That's
where libtool support for -rpath is necessary.

Bruno

[1] https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg0.html
[2] https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg1.html

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

[Roumen Petrov]

Hello,

When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Ileana Dumitrescu wrote:

Update of patch#10393 (group libtool):

   Status:None => Done
  Open/Closed:Open => Closed



[SNIP]

Regards,
Roumen Petrov

[patch #10393] Fix shared library support on Android

[Ileana Dumitrescu]

Update of patch#10393 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I went ahead and merged this in. Thanks for the patch!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Roumen Petrov]

Bruno Haible wrote:

URL:
   


[SNIP]


1) On this platform, libtool is configured to relink libraries during "make
install". This leads to a problem during the installation of libgettextsrc:
The relink command that libtool emits has the form
 
   $CC -shared -fPIC -DPIC .libs/*.o -L$(libdir) ... -lgettextlib ... -o

.libs/libgettextsrc-@VERSION@.soT
 
The option -lgettextlib resolves to $(libdir)/libgettextlib.a, not to
$(libdir)/libgettextlib-@VERSION@.so. 

[SNIP]

I cannot understand this.
If high level dependency is to lib FOO , i.e. -lFOO  why libtool should emit 
command lFOO-@VERSION@?

Android does not use "versioning" scheme.



2) The installed executables don't have a RUNPATH property that points to the
directory that contains the shared libraries. Thus these executables don't
run. 

It seems to me this is correct.
On Android is expected "relocatable" library and executable. Hard coded search 
path are not expected.


Roumen

[patch #10393] Fix shared library support on Android

[Bruno Haible]

URL:
  <https://savannah.gnu.org/patch/?10393>

 Summary: Fix shared library support on Android
   Group: GNU Libtool
   Submitter: haible
   Submitted: Mon 18 Sep 2023 01:25:06 PM CEST
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Mon 18 Sep 2023 01:25:06 PM CEST By: Bruno Haible 
On Android, within the termux environment, I encountered two problems during
the "make install" phase of GNU gettext. The attached patch fixes them.

1) On this platform, libtool is configured to relink libraries during "make
install". This leads to a problem during the installation of libgettextsrc:
The relink command that libtool emits has the form

  $CC -shared -fPIC -DPIC .libs/*.o -L$(libdir) ... -lgettextlib ... -o
.libs/libgettextsrc-@VERSION@.soT

The option -lgettextlib resolves to $(libdir)/libgettextlib.a, not to
$(libdir)/libgettextlib-@VERSION@.so. Thus the linker attempts to include many
object files from libgettextlib.a into libgettextsrc-@VERSION@.soT, but some
of these reference global variables in a non-PIC way, and the linker thus
complains

  ld.lld: error: relocation R_ARM_REL32 cannot be used against symbol
'program_name'; recompile with -fPIC

2) The installed executables don't have a RUNPATH property that points to the
directory that contains the shared libraries. Thus these executables don't
run.







___
File Attachments:


---
Date: Mon 18 Sep 2023 01:25:06 PM CEST  Name:
0001-Fix-shared-library-support-on-Android.patch  Size: 2KiB   By: haible

<http://savannah.gnu.org/patch/download.php?file_id=55144>

___

Reply to this item at:

  <https://savannah.gnu.org/patch/?10393>

___
Message sent via Savannah
https://savannah.gnu.org/