Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put

[Alan Modra <amodra at gmail dot com>]

On Sat, Apr 13, 2019 at 01:31:57PM -0400, Brian Groose wrote:
> I have not yet tried newer versions of gcc, though that's my next step
> as first I need 5.3.0.
> 
> I did check, and the symbols are definitely in libstdc++.a (apologies
> for the wrapping):
> 
> $ nm -C /opt/act-gcc-5.3.0/lib64/libstdc++.a | grep -F
> "std::ostreambuf_iterator<char, std::char_traits<char> >
> std::num_put<char, std::ostreambuf_iterator<char,
> std::char_traits<char> >
> >::_M_insert_int<long>(std::ostreambuf_iterator<char,
> std::char_traits<char> >, std::ios_base&, char, long) const"
>                  U std::ostreambuf_iterator<char,

The "U" here means you have a strong undefined symbol.

> std::char_traits<char> > std::num_put<char,
> std::ostreambuf_iterator<char, std::char_traits<char> >
> >::_M_insert_int<long>(std::ostreambuf_iterator<char,
> std::char_traits<char> >, std::ios_base&, char, long) const
> 0000000000001590 W std::ostreambuf_iterator<char,

With a weak definition here.

> std::char_traits<char> > std::num_put<char,
> std::ostreambuf_iterator<char, std::char_traits<char> >
> >::_M_insert_int<long>(std::ostreambuf_iterator<char,
> std::char_traits<char> >, std::ios_base&, char, long) const

That ought to work fine.  A weak undefined symbol doesn't cause the
linker to extract an object that has a definition for the symbols, but
you have a strong undefined symbol that does.

I'd be just that little bit more happy if you weren't displaying
demangled symbols since the linker works with the raw symbols, and
were showing the object file names with "nm -o".

> If I run 'ar x' for local-inst.o and wlocal-inst.o and add those two
> .o files to my linker command line, it successfully links.

OK, good.  That excludes a whole lot of other possible problems.

> My linker options, beyond local -L and -l for my own libraries, only
> has -Wl,-z,noexecstack -static-libgcc -static-libstdc++.  If I remove
> -static-libstdc++, it does link successfully as well, though to the
> shared version of course.
> 
> I'm just not sure what would cause ld fail to find symbols that are in
> the same .a but a different .o, I didn't think circular dependencies
> between .o files in the same .a would cause this type of issue as can
> happen when two .a files depend on each other.

Yes, that should be OK.  When the linker extracts compatibility-ldbl.o
from libstdc++.a it will notice this object adds more undefined
symbols.  That triggers a rescan over the archive.

>  Is there a table or
> index that might not be updated, as was the case in that previous bug?

Well, you could try running ranlib from your new binutils on
libstdc++.a.  ranlib creates the symbol map to object table in
archives used by the linker to decide which objects should be
extracted.

-- 
Alan Modra
Australia Development Lab, IBM