Changeset 9f9a9b4

Timestamp:

09/08/2023 01:49:06 PM (13 months ago)

Author:

Xi Ruoyao <xry111@…>

Branches:

12.1, 12.1-rc1, 12.2, 12.2-rc1, multilib, trunk, xry111/arm64, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.1, xry111/loongarch-12.2, xry111/mips64el, xry111/multilib, xry111/update-glibc

Children:

c7df34cb

Parents:

aa5fa04

git-author:

Xi Ruoyao <xry111@…> (09/08/2023 01:45:15 PM)

git-committer:

Xi Ruoyao <xry111@…> (09/08/2023 01:49:06 PM)

Message:

binutils-pass2: Reword the paragraph about libtool workaround

Well, I was blaming libtool too much. If the entire Binutils tree uses
libtool this won't happen. The problem is Binutils building system is
using libtool-style idiom on non-libtool components.

And this issue is not related to cross compiling, at all. A native
build can exploit the issue as well (see the updated comment).

Maybe I'll submit a patch to GCC (yes, not a typo, GCC is the upstream
of Binutils building system) to fix the issue when I have the mood...

File:

• chapter06/binutils-pass2.xml (modified) (1 diff)

chapter06/binutils-pass2.xml

@@ -44 +44 @@
     <title>Installation of Binutils</title>
 
-    <!-- Don't remove this until Binutils upstream updates the libtool
-         copy.  On some host distros the issue doesn't show up.  -->
-    <para>Binutils ships an outdated copy of libtool in the tarball.  It lacks
-    sysroot support, so the produced binaries will be mistakenly linked to
-    libraries from the host distro.  Work around this issue:</para>
+    <!-- Don't remove this until Binutils upstream resolves this issue.
+         We can test by building Binutils on a complete system with
+         zlib (libz.so) installed, passing enable-shared and
+         without-system-zlib.  If the resulted libctf.so still links against
+         libz.so (check with readelf -d) despite we are saying
+         without-system-zlib, then the issue is still unresolved.  -->
+    <para>Binutils relies on an internal libtool copy to link against
+    internal static libraries, but the libiberty and zlib copies shipped
+    in the package do not use libtool.  This inconsistency may cause
+    produced binaries mistakenly linked against libraries from the host
+    distro.  Work around this issue:</para>
 
 <screen><userinput remap="pre">sed '6009s/$add_dir//' -i ltmain.sh</userinput></screen>