[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#676569: gcc-4.7: -nostdlib broken, multiarch library path always added



severity 676569 normal
thanks

-nostdlib doesn't say anything about discarding the -L flags. Did this change
with 4.7?

On 07.06.2012 22:14, Thorsten Glaser wrote:
> Package: gcc-4.7
> Version: 4.7.0-12
> Severity: serious
> Justification: breaks unrelated software
> 
> The following scenario is broken: I would expect the link to fail.
> This is a carefully nailed-down testcase to figure out that the
> fault is with gcc not binutils.
> 
> tg@zigo:~ $ echo 'int login_tty(int); void _exit(int); void _start() { _exit(login_tty(0)); }' >test.c
> tg@zigo:~ $ rm -f test.out; gcc -nostdlib -lutil -o test.out test.c; ls -l test.out
> -rwxr-xr-x 1 tg tg 3712 Jun  7 20:09 test.out
> 
> Reason behind this is that GNU autoconf generated configure scripts
> (and other things like that) use such tests to check whether to add
> libraries providing certain functionality to the build. Now if klibc
> or dietlibc are used, you don't want to have libraries linked against
> eglibc added to the build, as that will eventually fail. Figured this
> out while trying to see whether jupp can be built with those libcs.
> 
> tg@zigo:~ $ gcc -nostdlib -lutil -o test.out test.c -v 2>&1 | tail -1
>  /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test.out -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lutil /tmp/ccjpTrCm.o
> tg@zigo:~ $ $(gcc -nostdlib -lutil -o test.out test.c -v -save-temps 2>&1 | tail -1) -t
> /usr/bin/ld.bfd.real: mode elf_x86_64
> -lutil (/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libutil.so)
> test.o
> 
> Here ^ we see "nicely" how gcc is the culprit adding -L directives,
> and that ld uses them at library resolution time.
> 
> tg@zigo:~ $ gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc-4.7.real
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-12' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --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.7.0 (Debian 4.7.0-12)




Reply to: