[Bug libstdc++/60348] New: -static-libstdc++ broken

[Bug libstdc++/60348] New: -static-libstdc++ broken

[nachms+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348

            Bug ID: 60348
           Summary: -static-libstdc++ broken
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nachms+gcc at gmail dot com

-static-libstdc++ does not seem to be working anymore.
Consider this following test application:

---------------------
#include <iostream>
#include <string>

int main()
{
  std::string s;
  if (s.empty()) { std::cout << "String is empty!" << std::endl; }
  return(0);
}
---------------------
g++ -Wall -o test test.cpp -static-libgcc -static-libstdc++

"test" here should not contain any references to libstdc++ symbols as it is
being linked statically, however, "objdump -T test" contains the following:
00000000006915c0 u    DO .bss   0000000000000020  Base       
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
0000000000691600 u    DO .bss   0000000000000020  Base       
_ZNSs4_Rep20_S_empty_rep_storageE

These are both symbols from libstdc++ that should have been staticaly linked,
yet they are now undefined, and indeed, this binary will not run on a system
without a sufficiently up to date libstdc++ installed.



Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--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.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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.8.2 (Debian 4.8.2-16)

GNU ld (GNU Binutils for Debian) 2.24

[Bug libstdc++/60348] -static-libstdc++ broken

[rguenth at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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 (0xf7700000)

Recompiling with -static-libgcc added gives:
0000000000690bc0 u    DO .bss   0000000000000020  Base       
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
0000000000690c00 u    DO .bss   0000000000000020  Base       
_ZNSs4_Rep20_S_empty_rep_storageE

And ldd:
        linux-vdso.so.1 (0x00007ffff011e000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fecae56b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fecae1c2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fecae8b1000)


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:
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc

[Bug libstdc++/60348] -static-libstdc++ broken

[glisse at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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
0000000000690c00      DO .bss   0000000000000020  Base       
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE

Where on Debian it gives:
0000000000690c00 u    DO .bss   0000000000000020  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

[glisse at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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

[nachms+gcc at gmail dot com]

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

[glisse at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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

[rguenth at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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

[rguenth at gcc dot gnu.org]

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

[nachms+gcc at gmail dot com]

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

[rguenth at gcc dot gnu.org]

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

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348

--- Comment #16 from Andreas Schwab <schwab@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

[nachms+gcc at gmail dot com]

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?