[patch #10393] Fix shared library support on Android

2023-09-18 Thread Bruno Haible
URL: 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:

[patch #10393] Fix shared library support on Android

2024-01-16 Thread Ileana Dumitrescu
Update of patch#10393 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: I went ahead and mer

[patch #10393] Fix shared library support on Android

2024-04-17 Thread 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. _

[patch #10393] Fix shared library support on Android

2024-04-17 Thread 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

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

2023-09-20 Thread 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 -s

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

2024-01-16 Thread 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. I

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

2024-01-16 Thread 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

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

2024-01-16 Thread 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.

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

2024-01-16 Thread 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

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

2024-01-17 Thread 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

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

2024-04-17 Thread 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 an