mainGNU Libtool - Support: sr #111011, restore previous shared library...

 
 

sr #111011: restore previous shared library logic on Android

Submitter:  Румен Петров <rpetrov>
Submitted:  Sun 28 Jan 2024 12:06:48 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  5 - Blocker Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 02 Sep 2024 01:28:35 PM UTC, comment #9: 

comment #8:

> Nothing personal - usefulness of "hard coded path" for Android and Windows is lie.


This is not a lie.

> Build tools are for general use not for personal one.


GNU Libtool is available for personal use.

> I'm sure that personal environment could be setup do not require hard coded paths.


This assumption and other generalisations that would limit the usage of GNU Libtool is not helpful or productive. Please refrain from opening a new issue on this until proper documentation and arguments can be provided that are not personally offensive to maintainers and contributers of GNU Libtool.

Ileana Dumitrescu <ildumi>
Group administrator
Sun 01 Sep 2024 12:32:46 PM UTC, comment #8: 

Nothing personal - usefulness of "hard coded path" for Android and Windows is lie.

Build tools are for general use not for personal one.

I'm sure that personal environment could be setup do not require hard coded paths.

Румен Петров <rpetrov>
Sun 01 Sep 2024 10:58:55 AM UTC, comment #7: 


> Goal of build tools is to help package manager(build engineer) to prepare installation.


No, that is not the only goal. Installation by individual users, on their own machines, is a goal of the GNU projects too. See:



> "Make sense" in this context is just a lie.


You should not drift into personal offense.

Bruno Haible <haible>
Sun 01 Sep 2024 10:34:45 AM UTC, comment #6: 

Last comment is misleading. Goal of build tools is to help package manager(build engineer) to prepare installation.

For private environment always exist work-around.

Use hardcoded paths on Windows and on Android does not make sense even in private(local) build. "Make sense" in this context is just a lie.



Румен Петров <rpetrov>
Sun 25 Aug 2024 01:36:20 PM UTC, comment #5: 


> Applications(programs) could be installed in any location(path)!


You seem to assume that programs are always meant to be installed on a different machine than on the one it was built.

This is not the case. The GNU project strives to make software modifiable and installable by individual users. Such users often build a package in order to use it only on that machine. In this situation, it does make sense to use hardcoded paths. (Both on Windows and on Android.)

Bruno Haible <haible>
Sun 25 Aug 2024 01:03:01 PM UTC, comment #4: 

Key rule: "Android and Microsoft Windows must not hard code any paths".

There is no room to discuss core functionality for both OS-ses. Applications(programs) could be installed in any location(path)!


Румен Петров <rpetrov>
Sat 24 Aug 2024 12:06:27 PM UTC, comment #3: 


> One recent commit broke Android build.


Nope. This commit of mine was explained in https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg00000.html

There are different environments on Android, as explained in https://lists.gnu.org/archive/html/bug-gnulib/2022-12/msg00100.html .

A statement like "Note that on Android and MIcrosoft Windows must not hard code any paths." is not helpful.

In the Android environment I am using, translating -rpath options to RUNPATH properties is mandatory.

If you are in an Android environment where RUNPATH options are not adequate, either pass '--disable-rpath' to the configure program, or find a way to reliably distinguish the two kinds of environments.

Bruno Haible <haible>
Sat 03 Feb 2024 03:43:10 PM UTC, comment #2: 

Note subject explain all.




One recent commit broke Android build. Patch just restore correct  behaviour that was used before.



Румен Петров <rpetrov>
Mon 29 Jan 2024 06:14:12 AM UTC, comment #1: 

this report lacks detailed (or really, any) information.  the git commit lacks detailed information, and the author e-mail is set to nonsense.

Mike Frysinger <vapier>
Group Member
Sun 28 Jan 2024 12:06:48 PM UTC, original submission:  

Recently rules for android linked was updated irrationally.
Attached patch restores previous correct(!) behaviour and updates  original remark.

Румен Петров <rpetrov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55661:  restore-shared-library-support-on-Android.patch added by rpetrov (1KiB - text/x-patch - patch email address updated )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ildumi (Posted a comment)
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by vapier (Posted a comment)
  • -email is unavailable- added by rpetrov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-09-02 ildumi Open/ClosedOpen Closed
        Summaryrestore shared library support on Android restore previous shared library logic on Android
    2024-09-02 ildumi StatusNone Wont Do
    2024-02-03 rpetrov Attached File- Added restore-shared-library-support-on-Android.patch, #55661
    2024-01-28 rpetrov Attached File- Added restore-shared-library-support-on-Android.patch, #55630

    Back to the top

    Powered by Savane 3.13-54b4.
    Corresponding source code