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.
