[Bug libstdc++/60348] -static-libstdc++ broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #18 from Andrew Pinski --- Invalid as the gcc you just compiled is that version of glibc and that version of glibc support unique objects.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It works for me. What does ldd test show? Do you have the static libstdc++/libgcc installed (Debian may package those separately?)
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #2 from Nach nachms+gcc at gmail dot com --- (In reply to Richard Biener from comment #1) It works for me. What does ldd test show? Do you have the static libstdc++/libgcc installed (Debian may package those separately?) ldd test linux-gate.so.1 (0xf76ff000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xf7676000) libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xf765a000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf74e7000) /lib/ld-linux.so.2 (0xf770) Recompiling with -static-libgcc added gives: 00690bc0 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 uDO .bss 0020 Base _ZNSs4_Rep20_S_empty_rep_storageE And ldd: linux-vdso.so.1 (0x7011e000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fecae56b000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fecae1c2000) /lib64/ld-linux-x86-64.so.2 (0x7fecae8b1000) I also want to confirm that I indeed have the static libstdc++ and libgcc installed. Furthermore, I've compiled huge C++ projects which use at least a dozen std::string methods, iostream, a ton of STL, and these are the only two symbols that are missing when using -static-libstdc++. Without -static-libstdc++, a lot of other libstdc++ symbols are now present in objdump, for example: DF *UND* GLIBCXX_3.4 _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- man nm: U The symbol is undefined. u The symbol is a unique global symbol. This is a GNU extension [...] The program does run fine for me with exactly the same compiler on debian. How did it fail to run for you, with what error message?
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #4 from Nach nachms+gcc at gmail dot com --- (In reply to Marc Glisse from comment #3) man nm: U The symbol is undefined. u The symbol is a unique global symbol. This is a GNU extension [...] The program does run fine for me with exactly the same compiler on debian. How did it fail to run for you, with what error message? The issue isn't that it can't run on a machine with a proper libstdc++ installed, the issue is that -static-libstdc++ is broken, meaning the binary cannot run on a system without libstdc++ installed (or a too old version). Trying to run the Debian compiled binary on RHEL5 is giving me: ./test: symbol lookup error: ./test: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE And on RHEL5 system: objdump -T ./test | grep _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 DO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Where on Debian it gives: 00690c00 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE In the past when -static-libstdc++ was working, binaries ran just fine on older systems.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Nach from comment #4) The issue isn't that it can't run on a machine with a proper libstdc++ installed, the issue is that -static-libstdc++ is broken, meaning the binary cannot run on a system without libstdc++ installed (or a too old version). Please don't guess what might be wrong. As strace would show, no libstdc++ is opened when executing test. Trying to run the Debian compiled binary on RHEL5 is giving me: ./test: symbol lookup error: ./test: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique help? Seems like your old system (ld.so?) gets confused by the new feature.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #6 from Nach nachms+gcc at gmail dot com --- Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique help? Seems like your old system (ld.so?) gets confused by the new feature. Doing so, there are no longer any u symbols appearing with objdump, nor those libstdc++ symbols appearing anywhere. Now, other systems are properly running the binary.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #7 from Nach nachms+gcc at gmail dot com --- Upon further testing, -fuse-ld=gold by itself without -Wl,--no-gnu-unique appears to get the job done.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- gold also produces the unique symbols. Main difference I can think of is visible in the output of file test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux)
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Thus, invalid.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Nach nachms+gcc at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #10 from Nach nachms+gcc at gmail dot com --- While you may be marking this as invalid, isn't there a serious issue here? Shouldn't -static-libstdc++ work without any special flags? Also, using -fuse-ld=gold seems to be breaking any application I have which links to non-system libraries.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #10) While you may be marking this as invalid, isn't there a serious issue here? Shouldn't -static-libstdc++ work without any special flags? But it works, doesn't it? That you cannot transfer the binary to some random system is because the compiler checks the features to use (like GNU unique symbols) when building GCC. That means it's a dependency on the dynamic linker of the system, not on libstdc++. Your program can end up using GNU unique symbols, too, which would then result in exactly the same issue.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #12 from Nach nachms+gcc at gmail dot com --- Isn't the whole point of -static-libstdc++ is to remove the dependency of libstdc++ from the binary? Even without the option, it does indeed work fine on the system it was compiled on. However, -static-libstdc++ currently does not appear to be doing its job, and I would NOT define it as *working*. For nearly 8 years I've been able to provide ready made binaries for practically any system (as long as glibc wasn't ancient). Now after a recent upgrade of build utilities, I can't seem to provide binaries for anyone who isn't using a distro from the past year or so. Even though these are large projects and make use of many statically linked binaries, the culprit as reported is missing libstdc++ symbols which in theory should not be happening if -static-libstdc++ is used, and the two aforementioned symbols are the only libstdc++ I see listed in the binary. Using older build utilities, I've never seen any libstdc++ symbols appear in a binary when -static-libstdc++ was used. Adding -fuse-ld=gold appears to be a *workaround* which works for the sample test case I used above. But if I try using -fuse-ld=gold with more complicated projects, the binary never even ends up linking, with a whole spew of missing symbols, which I know for a fact are contained in libraries which are being specified. If this in fact a bug with binutils and not libstdc++ or GCC, then fine, I don't mind reporting it elsewhere, just please assist me in understanding the issue so I can effectively do so.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #12) Isn't the whole point of -static-libstdc++ is to remove the dependency of libstdc++ from the binary? Even without the option, it does indeed work fine on the system it was compiled on. However, -static-libstdc++ currently does not appear to be doing its job, and I would NOT define it as *working*. The binary is not dependent on libstdc++ anymore and providing a libstdc++ on a system where the binary doesn't work won't fix it (because libstdc++ is not even loaded). For nearly 8 years I've been able to provide ready made binaries for practically any system (as long as glibc wasn't ancient). Now after a recent upgrade of build utilities, I can't seem to provide binaries for anyone who isn't using a distro from the past year or so. Even though these are large projects and make use of many statically linked binaries, the culprit as reported is missing libstdc++ symbols which in theory should not be happening if -static-libstdc++ is used, and the two aforementioned symbols are the only libstdc++ I see listed in the binary. Using older build utilities, I've never seen any libstdc++ symbols appear in a binary when -static-libstdc++ was used. Adding -fuse-ld=gold appears to be a *workaround* which works for the sample test case I used above. But if I try using -fuse-ld=gold with more complicated projects, the binary never even ends up linking, with a whole spew of missing symbols, which I know for a fact are contained in libraries which are being specified. If this in fact a bug with binutils and not libstdc++ or GCC, then fine, I don't mind reporting it elsewhere, just please assist me in understanding the issue so I can effectively do so. If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #14 from Nach nachms+gcc at gmail dot com --- (In reply to Richard Biener from comment #13) If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension. Okay thank you. Just one last question then, was there a specific version of GCC (and friends) that began using the glibc dynamic linker extension? Or to put it differently, how can I define whether a system has support for this extension? A certain minimum version of glibc?
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #14) (In reply to Richard Biener from comment #13) If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension. Okay thank you. Just one last question then, was there a specific version of GCC (and friends) that began using the glibc dynamic linker extension? Or to put it differently, how can I define whether a system has support for this extension? A certain minimum version of glibc? The minimum glibc version required is 2.11 IIRC, GCC 4.5 started to use this extension if available at build time.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #16 from Andreas Schwab sch...@linux-m68k.org --- If you want to build for old systems you need to use the old tools from those old systems and the output will still work on newer systems (backward compatiblity). New tools are using new features as they are available (no forward compatibility).
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #17 from Nach nachms+gcc at gmail dot com --- I just tried my above test case on RHEL6 without an up to date libstdc++ but with glibc 2.12, and the binary runs just fine. I double checked my old build system which does not produce these symbols, and I see it uses the following: Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --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.6 --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.6.3 (Debian 4.6.3-4) Note the --enable-gnu-unique-object. Also the system uses glibc 2.13. Any reason why this old build setup does not use these glibc unique symbols even though every indication is that it should?
