The testcase:

#include <string>
#include <iostream>

int
main (int argc, char *argv[])
{
    std::string myStr = "Hello, World!";
    std::cout << myStr << std::endl;
    return 0;
}

Before we do anything here, you should try to explain why the problem happens only on alpha, because on x86_64 it doesn't and those symbols are exported ("V"). Are the symbols exported on alpha? Are we **really** sure that aging target is otherwise ok, binutils included?

(In reply to comment #2)
> Before we do anything here, you should try to explain why the problem happens
> only on alpha, because on x86_64 it doesn't and those symbols are exported
> ("V"). Are the symbols exported on alpha? Are we **really** sure that aging
> target is otherwise ok, binutils included?

In the hope it helps, this is what I get from libstdc++-v3/src/.libs/libstdc++.a:

$ c++filt _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
std::num_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::id

$ nm libstdc++.a | grep _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
                 U _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
0000000000000000 u _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE

As shown, these symbols are exported as "u":

    `u'
          The symbol is a unique global symbol.  This is a GNU
          extension to the standard set of ELF symbol bindings.  For
          such a symbol the dynamic linker will make sure that in the
          entire process there is just one symbol with this name and
          type in use.

This is what I get on x86_64:

nm libstdc++.a | grep _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
                 U _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
                 U _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
0000000000000000 V _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE

thus, seems a target problem to me.

(In reply to comment #5)
> This is what I get on x86_64:

> thus, seems a target problem to me.

Do you have any advice, where/how these symbols get exported? I would like to analyze the failure, so we can blame some other tool ;)

(No, I'm not sure that binutils work correctly...)

In locale-inst.o

(In reply to comment #7)
> In locale-inst.o

Strange, on alpha it is defined in compatibility-ldbl.o.

Ah yes, it's probably because of the strange workarounds put in place for long double. Anyway, if you encounter special issues having to do with that, Jakub is the reference person.

(In reply to comment #9)
> Ah yes, it's probably because of the strange workarounds put in place for long
> double. Anyway, if you encounter special issues having to do with that, Jakub
> is the reference person.

Added to CC.

I belive this problem also shows on powerpc64-linux-gnu, configured with
--with-long-double-128 [1]:

FAIL: libmudflap.c++/pass28-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass28-frag.cxx (-static) compilation failed to produce executable
FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce executable
FAIL: libmudflap.c++/pass55-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass55-frag.cxx (-static) compilation failed to produce executable
FAIL: libmudflap.c++/pass57-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass57-frag.cxx (-static) compilation failed to produce executable

It looks that long-double support in libstdc++ is broken for certain symbols.

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00285.html

Can well be, personally I *never* checked -static on the targets affected by the 128 bit long double issue. I'm not even sure if Jakub himself did...

I guess this must be related to STB_GNU_UNIQUE, at least I can't reproduce this on ppc on Fedora 11 where STB_GNU_UNIQUE wasn't supported (even with recentish gcc), while according to log I see these
WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce executable
on ppc, ppc64, s390 and s390x when doing 4.4.*-RH package builds in Fedora 12+ where STB_GNU_UNIQUE is supported.

libstdc++.a symbols look good though:
0000000000000000 V _ZGVNSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
0000000000000000 u _ZNSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
0000000000000000 V _ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
0000000000000000 u _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE

(In reply to comment #13)
> I guess this must be related to STB_GNU_UNIQUE, at least I can't reproduce this
> on ppc on Fedora 11 where STB_GNU_UNIQUE wasn't supported (even with recentish
> gcc), while according to log I see these
> WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce
> executable
> on ppc, ppc64, s390 and s390x when doing 4.4.*-RH package builds in Fedora 12+
> where STB_GNU_UNIQUE is supported.

Thanks for your comments!

FYI, my binutils are "GNU ld (GNU Binutils) 2.20.1 20100303".

I don't know when binutils was upgraded, but looking back, I see that at the end of april, results on alpha for this test were clean [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02616.html

Ah, seems a generic ar/ranlib bug, apparently STB_GNU_UNIQUE symbols aren't added into ar index :(.
Wonder why it hasn't showed up elsewhere yet.  The reason why this doesn't hit us in libstdc++.a on x86-64 is that the STB_GNU_UNIQUE symbols locale-inst.o
needs are in locale-inst.o rather than compatibility-ldbl.o.
Looking into it.

Thanks Jakub.

Ah, already fixed:
http://sources.redhat.com/ml/binutils/2010-03/msg00249.html
http://sources.redhat.com/ml/binutils-cvs/2010-03/msg00143.html
http://sources.redhat.com/ml/binutils-cvs/2010-03/msg00144.html

(In reply to comment #15)
> Ah, seems a generic ar/ranlib bug, apparently STB_GNU_UNIQUE symbols aren't
> added into ar index :(.
> Wonder why it hasn't showed up elsewhere yet.  The reason why this doesn't hit
> us in libstdc++.a on x86-64 is that the STB_GNU_UNIQUE symbols locale-inst.o
> needs are in locale-inst.o rather than compatibility-ldbl.o.
> Looking into it.

Now that you mentioned - the problem was uncovered by [1]:

2010-04-28  Uros Bizjak  <ubizjak@gmail.com>

	* config/alpha/elf.h (ASM_DECLARE_OBJECT_NAME): Use gnu_unique_object
	type if available.

[1] http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01751.html

I wonder if the ar/ranlib bug is severe enough that we need to check for newer version of the binutils in configure.ac. Currently we have:

 [gcc_GAS_CHECK_FEATURE([gnu_unique_object], gcc_cv_as_gnu_unique_object,
   [elf,2,19,52],,

Not a gcc bug.