Bug#786883: gcc-4.9: --sysroot=... not properly respected - /usr/lib still stays in library search path
Package: gcc-4.9
Version: 4.9.2-18
Severity: normal
Dear Maintainer,
I'm trying to re-prefix gcc at runtime and found that --sysroot option
is not properly respected - /usr/lib/ still stays in ld search path.
Here is an example
$ pwd
/home/kirr/tmp/gcc-sysroot # NOTE - non / nor /usr/...
$ mkdir root # NOTE it will stay _empty_
$ cat prog.c # test program to compile/link
int main() { return 0; }
$ gcc --sysroot=`pwd`/root prog.c # NOTE links ok. But it should
$ echo $? # complain that it cannot find
0 # e.g. crt1.o
# like e.g. gcc-snapshot is complaining
$ /usr/lib/gcc-snapshot/bin/gcc --sysroot=`pwd`/root prog.c
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
# though without --sysroot gcc-snapshot builds it ok:
$ /usr/lib/gcc-snapshot/bin/gcc prog.c
$ echo $?
0
I've investigated a bit with `gcc -v`:
$ gcc -v --sysroot=`pwd`/root prog.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-18' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --
with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-18)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/cc1 -quiet -v -imultiarch x86_64-linux-gnu -isysroot /home/kirr/tmp/gcc-sysroot/root prog.c -quiet -dumpbase prog.c -mtune=generic -march=x86-64 -auxbase prog -version -o /tmp/cc7D9nYw.s
GNU C (Debian 4.9.2-18) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/home/kirr/tmp/gcc-sysroot/root/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/home/kirr/tmp/gcc-sysroot/root/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/home/kirr/tmp/gcc-sysroot/root/usr/include/x86_64-linux-gnu"
ignoring nonexistent directory "/home/kirr/tmp/gcc-sysroot/root/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.9/include
/usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed
End of search list.
GNU C (Debian 4.9.2-18) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 514e8e7b9ffc2d28024c8135005ee4c0
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccvJZhce.o /tmp/cc7D9nYw.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccLSDzrV.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/home/kirr/tmp/gcc-sysroot/root --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. /tmp/ccvJZhce.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /
usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
and the reason for not dropping /usr/lib , it seems, is because of e.g.
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
(realpath = /usr/lib/x86_64-linux-gnu/crt1.o)
being used as C-runtime support from libc, and then internally gcc for %D in
it's spec "Dump out a -L option for each directory in startfile_prefixes":
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;h=c7ce64d8fc864c2f8cf46269e020b86b637437ff;hb=b7c27a04cdf50ecaedd163a06b12c9d8753357aa#l379
and %D is used for link_linkgcc:
$ gcc -dumpspecs |grep -A2 '^\*link_libgcc'
*link_libgcc:
%D
so it looks like it picks up /usr/lib/x86_64-linux-gnu/crt1.o (maybe correct)
and then whenever libgcc should be linked in (almost always) adds
-L/usr/lib/x86_64-linux-gnu in correspondence to it (wrong).
... which breaks sysroot promise - we can (unintentionally) link with
system libraries besides libc installed in /usr - look e.g.:
$ gcc --sysroot=`pwd`/root prog.c -lcrypto
/usr/bin/ld: warning: libdl.so.2, needed by /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlopen@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlerror@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlclose@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlsym@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dladdr@GLIBC_2.2.5'
collect2: error: ld returned 1 exit status
it picks up /usr/lib/x86_64-linux-gnu/libcrypto.so !
(= realpath /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcrypto.so)
the compilation failed just by luck, for some reason, but it succeeds with both -lcrypto -ldl:
$ gcc --sysroot=`pwd`/root prog.c -lcrypto -ldl
$ echo $?
0
and both libraries were picked from /usr/lib/x86_64-linux-gnu because root/ is
completely _empty_ !
~~~~
I guess gcc-snapshot succeeds not because the bug was fixed, but because it is
maybe configured at different-than /usr prefix (/usr/lib/gcc-snapshot) -
because I've tried to compile gcc-4_9-branch manually, with also
different-from-usr prefix, and that manually compiled gcc respects --sysroot ok.
With this situation, when standard search paths are still being used, it is not
possible to rely on --sysroot promise:
---- 8<---- from gcc(1)
--sysroot=dir
Use dir as the logical root directory for headers and libraries.
For example, if the compiler normally searches for headers in
/usr/include and libraries in /usr/lib, it instead searches
dir/usr/include and dir/usr/lib.
I would appreciate, if it possible to fix.
Thanks beforehand,
Kirill
P.S.
$ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20150516-1) 6.0.0 20150516 (experimental) [trunk revision 223239]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages gcc-4.9 depends on:
ii binutils 2.25-7
ii cpp-4.9 4.9.2-18
ii gcc-4.9-base 4.9.2-18
ii libc6 2.19-18
ii libcloog-isl4 0.18.3-1
ii libgcc-4.9-dev 4.9.2-18
ii libgmp10 2:6.0.0+dfsg-6
ii libisl13 0.14-2
ii libmpc3 1.0.3-1
ii libmpfr4 3.1.2-3
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages gcc-4.9 recommends:
ii libc6-dev 2.19-18
Versions of packages gcc-4.9 suggests:
ii gcc-4.9-doc 4.9.2-2
pn gcc-4.9-locales <none>
ii gcc-4.9-multilib 4.9.2-18
pn libasan1-dbg <none>
pn libatomic1-dbg <none>
pn libcilkrts5-dbg <none>
ii libgcc1-dbg 1:5.1.1-7
pn libgomp1-dbg <none>
pn libitm1-dbg <none>
pn liblsan0-dbg <none>
pn libquadmath0-dbg <none>
pn libtsan0-dbg <none>
pn libubsan0-dbg <none>
-- no debconf information
Reply to: