[Bug libctf/28905] New: libtool causes libctf.so links to system zlib on cross compilation

[xry111 at mengyan1223 dot wang]

https://sourceware.org/bugzilla/show_bug.cgi?id=28905

            Bug ID: 28905
           Summary: libtool causes libctf.so links to system zlib on cross
                    compilation
           Product: binutils
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libctf
          Assignee: unassigned at sourceware dot org
          Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

Consider cross-compiling binutils for a sysroot, then install it into the
sysroot (with DESTDIR) and move the sysroot onto the target machine.  Then we
should be able to build packages on the target machine with binutils (and GCC,
but it's another topic) just built.

However, we hit a problem when the target machine and the build machine
*happen* to be compatible.  We configure binutils like this:

../configure                   \
    --prefix=/usr              \
    --build=$(../config.guess) \
    --host=$TARGET_TRIPLE      \
    --disable-nls              \
    --enable-shared            \
    --disable-werror

Then binutils build fine (with $TARGET_TRIPLE-gcc and $TARGET_TRIPLE-ld etc,
all configured with sysroot). Then we want to use DESTDIR to install binutils
into the sysroot, like:

    make install DESTDIR=/mnt/build_dir/sources/sysroot

libctf.la is then relinked with:

libtool: install: warning: relinking `libctf.la'
libtool: install: (cd /mnt/build_dir/sources/binutils-2.38/build/libctf;
/bin/sh /mnt/build_dir/sources/binutils-2.38/build/libctf/libtool  --silent
--tag CC --mode=relink x86_64-lfs-linux-gnu-gcc -std=gnu99 -Wall -W -Wall
-Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long
-I../../libctf/../zlib -g -O2 -version-info 0:0:0
-Wl,--version-script=../../libctf/libctf.ver -o libctf.la -rpath /usr/lib
libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo
libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo
libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo
libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo
libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo
libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-open-bfd.lo
-L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic -liberty
../bfd/libbfd.la
-L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic -liberty
-L./../zlib -lz -inst-prefix-dir /mnt/build_dir/sources/sysroot)

It seems OK, but "../bfd/libbfd.la" contains:

    libdir='/usr/lib'

At ltmain.sh:6003:

    # We cannot seem to hardcode it, guess we'll fake it.
    add_dir="-L$libdir"

This effectively add "-L/usr/lib" into the $TARGET_TRIPLE-gcc command line. 
The command line is now like:

$TARGET_TRIPLE-gcc -shared  -fPIC -DPIC  .libs/libctf_la-ctf-archive.o ... ...
-L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic
-L/mnt/build_dir/sources/sysroot/usr/lib -L/usr/lib -lbfd
-L/mnt/build_dir/sources/binutils-2.38/build/bfd/../libiberty/pic
-L/mnt/build_dir/sources/binutils-2.38/build/zlib -liberty -lz 
-Wl,--version-script=../../libctf/libctf.ver   -Wl,-soname -Wl,libctf.so.0 -o
.libs/libctf.so.0.0.0

"-L/usr/lib ... -lz" causes system zlib (/usr/lib/libz.so) to be used, instead
of our shipped zlib (/mnt/build_dir/sources/binutils-2.38/build/zlib/libz.a). 
But libz.so does not exist in the sysroot, so we can't use binutils after
moving the sysroot onto the target machine.

Maybe the "Component" shouldn't be libctf: libopcodes suffers the same issue. 
But there is not a "building system" component in bugzilla...

-- 
You are receiving this mail because:
You are on the CC list for the bug.