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

Bug#676569: marked as done (gcc-4.7: -nostdlib broken, multiarch library path always added)

Your message dated Sat, 08 Sep 2012 15:47:17 +0200
with message-id <504B4C65.8060807@debian.org>
and subject line Re: Bug#676569: gcc-4.7: -nostdlib broken, multiarch library path always added
has caused the Debian Bug report #676569,
regarding gcc-4.7: -nostdlib broken, multiarch library path always added
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
676569: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676569
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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)


-- System Information:
Debian Release: wheezy/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
m68k

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages gcc-4.7 depends on:
ii  binutils      2.22-6.1
ii  cpp-4.7       4.7.0-12
ii  gcc-4.7-base  4.7.0-12
ii  libc6         2.13-33
ii  libgcc1       1:4.7.0-12
ii  libgmp10      2:5.0.5+dfsg-2
ii  libgomp1      4.7.0-12
ii  libitm1       4.7.0-12
ii  libmpc2       0.9-4
ii  libmpfr4      3.1.0-5
ii  libquadmath0  4.7.0-12
ii  zlib1g        1:1.2.7.dfsg-11

Versions of packages gcc-4.7 recommends:
ii  libc6-dev  2.13-33

Versions of packages gcc-4.7 suggests:
pn  binutils-gold        <none>
pn  gcc-4.7-doc          <none>
pn  gcc-4.7-locales      <none>
pn  gcc-4.7-multilib     <none>
pn  libgcc1-dbg          <none>
pn  libgomp1-dbg         <none>
pn  libitm1-dbg          <none>
pn  libmudflap0-4.7-dev  <none>
pn  libmudflap0-dbg      <none>
pn  libquadmath0-dbg     <none>

-- no debconf information

--- End Message ---
--- Begin Message --- 
On 13.06.2012 15:51, Thorsten Glaser wrote:
> Matthias Klose dixit:
> 
>> -nostdlib doesn't say anything about discarding the -L flags. Did this change
>> with 4.7?
> 
> Hm, actually, it doesn’t.

ok, closing this issue.

> What’s the option to do so, then? I have always been under the
> impression that -nostdlib would include this behaviour.

implement and submit a patch upstream (and get it accepted).

--- End Message ---
Reply to: