Subject: bug#73620: closed (Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 10 Oct 2024 14:41:02 +0000

Your bug report

#73620: libtool-2.5.3 broken on CentOS and Alma Linux

which was filed against the libtool package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
73620: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73620
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
From: Ileana Dumitrescu <[email-masked]>
To: [email-masked]
Cc: Sergey Poznyakoff <[email-masked]>, Bruno Haible <[email-masked]>, Sam James <[email-masked]>
Date: Thu, 10 Oct 2024 17:39:15 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

On 10/10/2024 00:04, Bruno Haible wrote:
> Sergey Poznyakoff wrote:
>> Ileana is absolutely right: the reason for this behavior is that some
>> paths are excluded from compile_rpath in func_mode_link.  The original
>> idea was to prevent paths from outside of the source tree from appearing
>> before ones lying beneath it.  However, simply omitting such paths was
>> not right, they should be reordered instead.  The attached patch fixes
>> this.  With it, both bug_71489.at in libtool, and all tests in gettext
>> pass.
>

I am glad I understood correctly, and thank you for the patch!

> Thanks. I confirm that with this patch, all gettext tests pass. The xgettext
> wrapper script (attached) now has the complete relink command:
> 
> with libtool-2.5.3:
> relink_command="(... -Wl,-rpath -Wl,/home/bruno/inst-x86_64-64/lib)"
> with your new patch added:
> relink_command="(... -Wl,-rpath -Wl,/home/bruno/gettext-2024-10-02/build-64/libtextstyle/lib/.libs -Wl,-rpath -Wl,/home/bruno/inst-x86_64-64/lib)"
> 
> Ileana Dumitrescu wrote:
>> The relink command seems to be set by fast_install=yes:
> 
> Indeed, there is a difference here.
> 
> On Ubuntu 22.04:
> 
> $ grep fast_install ./gettext-runtime/libasprintf/config.status ./gettext-runtime/intl/config.status ./gettext-runtime/config.status ./libtextstyle/config.status ./gettext-tools/config.status
> ./gettext-runtime/libasprintf/config.status:enable_fast_install='needless'
> ./gettext-runtime/libasprintf/config.status:fast_install=$enable_fast_install
> ./gettext-runtime/intl/config.status:enable_fast_install='needless'
> ./gettext-runtime/intl/config.status:fast_install=$enable_fast_install
> ./gettext-runtime/config.status:enable_fast_install='needless'
> ./gettext-runtime/config.status:fast_install=$enable_fast_install
> ./libtextstyle/config.status:enable_fast_install='needless'
> ./libtextstyle/config.status:fast_install=$enable_fast_install
> ./gettext-tools/config.status:enable_fast_install='needless'
> ./gettext-tools/config.status:fast_install=$enable_fast_install
> 
> On Alma Linux 9:
> 
> $ grep fast_install ./gettext-runtime/libasprintf/config.status ./gettext-runtime/intl/config.status ./gettext-runtime/config.status ./libtextstyle/config.status ./gettext-tools/config.status
> ./gettext-runtime/libasprintf/config.status:enable_fast_install='yes'
> ./gettext-runtime/libasprintf/config.status:fast_install=$enable_fast_install
> ./gettext-runtime/intl/config.status:enable_fast_install='yes'
> ./gettext-runtime/intl/config.status:fast_install=$enable_fast_install
> ./gettext-runtime/config.status:enable_fast_install='yes'
> ./gettext-runtime/config.status:fast_install=$enable_fast_install
> ./libtextstyle/config.status:enable_fast_install='yes'
> ./libtextstyle/config.status:fast_install=$enable_fast_install
> ./gettext-tools/config.status:enable_fast_install='yes'
> ./gettext-tools/config.status:fast_install=$enable_fast_install
> 
> Where does this difference come from?
> hardcode_action is 'immediate' in both cases.
> inherit_rpath is 'no' in both cases.
> shlibpath_overrides_runpath is 'yes' on Ubuntu, 'no' on Alma Linux.
> Apparently the difference comes from the configure test marked with a comment
> "Some binutils ld are patched to set DT_RUNPATH"
> 
> Bruno
> 

Thank you for explaining how this works and differs between Ubuntu and 
Alma Linux. :)

I have applied the patch to the development branch [1], and I plan to
make another stable release soon for this and some other patches I have
not applied yet.

[1] 
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=44ad06b0d260d4a6ac0f90834d505e1ee0077d53

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Subject: libtool-2.5.3 broken on CentOS and Alma Linux
From: Bruno Haible <[email-masked]>
To: [email-masked]
Date: Fri, 04 Oct 2024 01:00:09 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

In GNU gettext's CI, two months ago, I started using libtool-2.5.1.
All fine on all platforms.

This week, I upgraded to libtool-2.5.3, and what I see is that most
unit tests fail on CentOS 7 and Alma Linux 9, i.e. both RHEL compatible
distros.

How to reproduce:
0. Use a machine with Alma Linux 9 (e.g. from AlmaLinux-9.0-x86_64-dvd.iso
   with VirtualBox or QEMU).
1. Download the tarball generated by the CI:
  $ wget https://alpha.gnu.org/gnu/gettext/gettext-2024-10-02.tar.gz
2. Unpack
  $ tar xfz gettext-2024-10-02.tar.gz
3. Build
  $ mkdir build-64
  $ cd build-64
  $ ../configure
  $ make
  $ make check

Apparently the wrapper executables for most programs in gettext-tools/src/
are dysfunctional.

When I try to run one, in particular:
  $ cd gettext-tools/src
  $ ./xgettext --help
  /home/bruno/gettext-2024-10-02/build-64/gettext-tools/src/.libs/lt-xgettext: error while loading shared libraries: libtextstyle.so.0: cannot open shared object file: No such file or directory

But libtextstyle.so.0 exists in the build tree, at
  /home/bruno/gettext-2024-10-02/build-64/libtextstyle/lib/.libs/libtextstyle.so.0

I'm attaching the xgettext wrapper scripts
  - from Ubuntu 22.04 (where it works)
  - from Alma Linux 9 (where it is broken)

You can see that the main difference is that on Alma Linux, a relink command is
being used. This raises two questions:

  1) Why is the relink command not working? (Recall that omitting the relink
     is just an optimization.)

  2) Why is the "omit the relink" optimization not activated?

Bruno