GNU bug report logs - #73620
libtool-2.5.3 broken on CentOS and Alma Linux

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73620 in the body.
You can then email your comments to 73620 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-libtool <at> gnu.org
Subject: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Fri, 04 Oct 2024 01:00:09 +0200

[Message part 1 (text/plain, inline)]

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

[ubuntu-xgettext-wrapper (application/x-shellscript, attachment)]

[alma9-xgettext-wrapper (application/x-shellscript, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-libtool <at> gnu.org
Subject: Re: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Wed, 09 Oct 2024 15:59:58 +0200

Hi,

I wrote:
> 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.

When I revert the ltmain.in change from commit
0e1b33332429cd578367bd0ad420c065d5caf0ac,
things work again.

Bruno

Message #11 received at 73620 <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> gentoo.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: gray <at> gnu.org.ua, 73620 <at> debbugs.gnu.org
Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Wed, 09 Oct 2024 15:32:20 +0100

Bruno Haible <bruno <at> clisp.org> writes:

> Hi,
>
> I wrote:
>> 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.
>
> When I revert the ltmain.in change from commit
> 0e1b33332429cd578367bd0ad420c065d5caf0ac,
> things work again.
>

CCing Sergey.

> Bruno

Message #14 received at 73620 <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 73620 <at> debbugs.gnu.org
Cc: Bruno Haible <bruno <at> clisp.org>, gray <at> gnu.org.ua, Sam James <sam <at> gentoo.org>
Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Wed, 9 Oct 2024 19:01:32 +0300

[Message part 1 (text/plain, inline)]

On 09/10/2024 17:32, Sam James wrote:
> Bruno Haible <bruno <at> clisp.org> writes:
> 
>> Hi,
>>
>> I wrote:
>>> 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.
>>
>> When I revert the ltmain.in change from commit
>> 0e1b33332429cd578367bd0ad420c065d5caf0ac,
>> things work again.
>>
> 
> CCing Sergey.
> 
>> Bruno
> 

I have been looking into this, but I am sure Sergey will be faster than
me at diagnosing and solving the issue.

The relink command is most likely not working due to omissions of
appending absdir to compile_rpath:

BEFORE commit:
"""
      case "$compile_rpath " in
      *" $absdir "*) ;;
      *) func_append compile_rpath " $absdir" ;;
      esac

"""
AFTER commit:
"""
      case "$compile_rpath " in
      *" $absdir "*) ;;
      *) case $absdir in
         "$progdir/"*) func_append compile_rpath " $absdir" ;;
	 esac
      esac
"""

The relink command seems to be set by fast_install=yes:

"""
      case $hardcode_action,$fast_install in
        relink,*)
	  # Fast installation is not supported
	  link_command=$compile_var$compile_command$compile_rpath
	  relink_command=$finalize_var$finalize_command$finalize_rpath

	  func_warning "this platform does not like uninstalled shared libraries"
	  func_warning "'$output' will be relinked during installation"
	  ;;
        *,yes)
	  link_command=$finalize_var$compile_command$finalize_rpath
	  relink_command=`$ECHO "$compile_var$compile_command$compile_rpath" | 
$SED 's%@OUTPUT@%\$progdir/\$file%g'`
          ;;
	*,no)
	  link_command=$compile_var$compile_command$compile_rpath
	  relink_command=$finalize_var$finalize_command$finalize_rpath
          ;;
	*,needless)
	  link_command=$finalize_var$compile_command$finalize_rpath
	  relink_command=
          ;;
      esac
"""

The relevant code generating part of the xgettext wrapper script for 
Alma Linux 9:

"""
if test yes = "$fast_install"; then
	  $ECHO "\
  program=lt-'$outputname'$exeext
  progdir=\"\$thisdir/$objdir\"

  if test ! -f \"\$progdir/\$program\" ||
     { file=\`ls -1dt \"\$progdir/\$program\" 
\"\$progdir/../\$program\" 2>/dev/null | $SED 1q\`; \\
       test \"X\$file\" != \"X\$progdir/\$program\"; }; then

    file=\"\$\$-\$program\"

    if test ! -d \"\$progdir\"; then
      $MKDIR \"\$progdir\"
    else
      $RM \"\$progdir/\$file\"
    fi"

	  $ECHO "\

    # relink executable if necessary
    if test -n \"\$relink_command\"; then
      if relink_command_output=\`eval \$relink_command 2>&1\`; then :
      else
	\$ECHO \"\$relink_command_output\" >&2
	$RM \"\$progdir/\$file\"
	exit 1
      fi
    fi

    $MV \"\$progdir/\$file\" \"\$progdir/\$program\" 2>/dev/null ||
    { $RM \"\$progdir/\$program\";
      $MV \"\$progdir/\$file\" \"\$progdir/\$program\"; }
    $RM \"\$progdir/\$file\"
  fi"
	else
	  $ECHO "\
  program='$outputname'
  progdir=\"\$thisdir/$objdir\"
"
	fi
"""

I may be wrong, but this is what I think is happening. I would be happy 
to have other opinions though.

-- 
Ileana Dumitrescu

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

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Message #17 received at 73620 <at> debbugs.gnu.org (full text, mbox):

From: "Sergey Poznyakoff" <gray <at> gnu.org.ua>
To: "Ileana Dumitrescu" <ileanadumitrescu95 <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 73620 <at> debbugs.gnu.org,
 Sam James <sam <at> gentoo.org>
Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Wed, 09 Oct 2024 21:21:53 +0200

[Message part 1 (text/plain, inline)]

Hello,

Thanks a lot for CCing me.

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.

Regards,
Sergey

[0001-Don-t-omit-directories-from-the-constructed-rpath.patch (text/x-diff, inline)]

From 1b5a235b47f61ba1adb331db7f084630ac110f5b Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff <gray <at> gnu.org>
Date: Wed, 9 Oct 2024 21:34:01 +0300
Subject: [PATCH] Don't omit directories from the constructed rpath.

This fixes bug introduced by 0e1b333324.

* build-aux/ltmain.in: Don't omit paths that are not under $progdir
from the compiled_rpath.  Append them to the end of it.
---
 build-aux/ltmain.in | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 68aca605..2c486fa7 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -4632,6 +4632,7 @@ func_mode_link ()
     finalize_command=$nonopt

     compile_rpath=
+    compile_rpath_tail=
     finalize_rpath=
     compile_shlibpath=
     finalize_shlibpath=
@@ -6273,10 +6274,11 @@ func_mode_link ()
 	    case " $sys_lib_dlsearch_path " in
 	    *" $absdir "*) ;;
 	    *)
-	      case "$compile_rpath " in
+	      case "$compile_rpath$compile_rpath_tail " in
 	      *" $absdir "*) ;;
 	      *) case $absdir in
                  "$progdir/"*) func_append compile_rpath " $absdir" ;;
+                 *) func_append compile_rpath_tail " $absdir" ;;
 		 esac
 	      esac
 	      ;;
@@ -6349,10 +6351,11 @@ func_mode_link ()
 	    case " $sys_lib_dlsearch_path " in
 	    *" $absdir "*) ;;
 	    *)
-	      case "$compile_rpath " in
+	      case "$compile_rpath$compile_rpath_tail " in
 	      *" $absdir "*) ;;
 	      *) case $absdir in
                  "$progdir/"*) func_append compile_rpath " $absdir" ;;
+                 *) func_append compile_rpath_tail " $absdir" ;;
 		 esac
 	      esac
 	      ;;
@@ -6716,6 +6719,8 @@ func_mode_link ()
       done # for deplib in $libs

       func_append temp_rpath "$temp_rpath_tail"
+      func_append compile_rpath "$compile_rpath_tail"
+
       if test link = "$pass"; then
 	if test prog = "$linkmode"; then
 	  compile_deplibs="$new_inherited_linker_flags $compile_deplibs"
--
2.35.1

Message #20 received at 73620 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>,
 Sergey Poznyakoff <gray <at> gnu.org.ua>
Cc: 73620 <at> debbugs.gnu.org, Sam James <sam <at> gentoo.org>
Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Wed, 09 Oct 2024 23:04:05 +0200

[Message part 1 (text/plain, inline)]

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.

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

[alma9-new-xgettext-wrapper (application/x-shellscript, attachment)]

Message #25 received at 73620-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 73620-done <at> debbugs.gnu.org
Cc: Sergey Poznyakoff <gray <at> gnu.org.ua>, Bruno Haible <bruno <at> clisp.org>,
 Sam James <sam <at> gentoo.org>
Subject: Re: bug#73620: libtool-2.5.3 broken on CentOS and Alma Linux
Date: Thu, 10 Oct 2024 17:39:15 +0300

[Message part 1 (text/plain, inline)]

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

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.