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

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

[Brian Groose]

It looks like I'm hitting the same issue that was reported in this
invalid gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43968,
which was closed because it is a binutils bug?

I'm getting the exact same errors but running Linux on ppc64 instead
of alpha.  I have built binutils 2.25.1 and 2.32 from source, and both
have hit the same linker errors as in that gcc bug.  The same code
with the same binutils and gcc versions links without error on Linux
x86 and x64 (and 32-bit Solaris targets).

I am NOT linking with -static, though I am using -static-libgcc and
-static-libstdc++.  I am unable to reproduce this with a small test
case program such as the one found in the gcc bug.

Can anyone give me any suggestions of things to try here or what might be wrong?

/opt/gcc-5.3.0/lib/gcc/powerpc64-unknown-linux-gnu/5.3.0/../../../../lib64/libstdc++.a(compatibility-ldbl.o):
In function `std::num_put<char, std::ostreambuf_iterator<char,
std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char,
std::char_traits<char> >, std::ios_base&, char, long) const':
/root/gcc/gcc-5.3.0-sandbox/build-gcc/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2510:
undefined reference to `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'

... and more, with just the type passed to do_put changing - unsigned
long, void const*, long long, unsigned long long - and then wchar_t
versions of the same.  Followed by:

/opt/gcc-5.3.0/lib/gcc/powerpc64-unknown-linux-gnu/5.3.0/../../../../lib64/libstdc++.a(compatibility-ldbl.o):
In function `std::num_put<wchar_t, std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> >
>::do_put(std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t>
>, std::ios_base&, wchar_t, long) const':
/root/gcc/gcc-5.3.0-sandbox/build-gcc/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2510:
undefined reference to `std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> > std::num_put<wchar_t,
std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> >
>::_M_insert_int<long>(std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> >, std::ios_base&, wchar_t, long) const'

...  with the same type variations to follow.

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

[Alan Modra]

On Wed, Apr 10, 2019 at 12:52:59PM -0400, Brian Groose wrote:
> It looks like I'm hitting the same issue that was reported in this
> invalid gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43968,
> which was closed because it is a binutils bug?

No, that old ar bug won't be the trouble here.

> I'm getting the exact same errors but running Linux on ppc64 instead
> of alpha.  I have built binutils 2.25.1 and 2.32 from source, and both
> have hit the same linker errors as in that gcc bug.  The same code
> with the same binutils and gcc versions links without error on Linux
> x86 and x64 (and 32-bit Solaris targets).
> 
> I am NOT linking with -static, though I am using -static-libgcc and
> -static-libstdc++.  I am unable to reproduce this with a small test
> case program such as the one found in the gcc bug.
> 
> Can anyone give me any suggestions of things to try here or what might be wrong?

I don't know what to suggest with the few details you've supplied.
I think you'll find that the missing compatibility-ldbl.o symbols are
defined in locale-inst.o, also in libstdc++.a.  So it's a mystery why
they don't satisfy the references.  Have you tried newer versions of
gcc?

-- 
Alan Modra
Australia Development Lab, IBM

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

[Brian Groose]

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,
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,
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

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.

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.  Is there a table or
index that might not be updated, as was the case in that previous bug?



On Fri, Apr 12, 2019 at 10:57 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Apr 10, 2019 at 12:52:59PM -0400, Brian Groose wrote:
> > It looks like I'm hitting the same issue that was reported in this
> > invalid gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43968,
> > which was closed because it is a binutils bug?
>
> No, that old ar bug won't be the trouble here.
>
> > I'm getting the exact same errors but running Linux on ppc64 instead
> > of alpha.  I have built binutils 2.25.1 and 2.32 from source, and both
> > have hit the same linker errors as in that gcc bug.  The same code
> > with the same binutils and gcc versions links without error on Linux
> > x86 and x64 (and 32-bit Solaris targets).
> >
> > I am NOT linking with -static, though I am using -static-libgcc and
> > -static-libstdc++.  I am unable to reproduce this with a small test
> > case program such as the one found in the gcc bug.
> >
> > Can anyone give me any suggestions of things to try here or what might be wrong?
>
> I don't know what to suggest with the few details you've supplied.
> I think you'll find that the missing compatibility-ldbl.o symbols are
> defined in locale-inst.o, also in libstdc++.a.  So it's a mystery why
> they don't satisfy the references.  Have you tried newer versions of
> gcc?
>
> --
> Alan Modra
> Australia Development Lab, IBM

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

[Alan Modra]

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

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

[Brian Groose]

On Sun, Apr 14, 2019 at 7:16 PM Alan Modra <amodra@gmail.com> wrote:
> On Sat, Apr 13, 2019 at 01:31:57PM -0400, Brian Groose wrote:
>
> > 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.

Someone in the gcc-help mailing list suggested adding -lstdc++ to the
linker line, and that actually worked as well.

> >  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.

I tried that and it didn't work, unfortunately.

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

[Alan Modra]

On Mon, Apr 22, 2019 at 12:04:25PM -0400, Brian Groose wrote:
> Everything can be dropped into one directory and fails to link with this
> /PATH/TO/NEWER/G++/g++ -L. -Wl,-z,noexecstack -static-libgcc
> -static-libstdc++ -g *.o -lvirtualization -lagtframework
> -lvirtualization -ldas -loracle -lgeneric -lnas -lsystemstate
> -lstoragemgmt -lsmartcopy -lagtframework -lagentutils -ludplinuxutils
> -ludpzfsutils -lpthread -lrt -Wl,-Bstatic -lACE -lssl -lcrypto -lz
> -lxml2 -lboost_chrono -lboost_filesystem -lboost_locale
> -lboost_program_options -lboost_system -lboost_thread -Wl,-Bdynamic
> -ldl -lrt -lpam -o udsagent

OK, minus the -lpam I can link this and reproduce the problem here.

libboost_locale.a is the culprit.

The first complaint about an undefined symbol (linking with
-Wl,--no-demangle) is
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES3_S3_RSt8ios_basecT_

This is actually defined in libstdc++.a(locale-inst.o) .opd section
(it's a function descriptor) an alias for
_ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
with the corresponding code in section
.text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_

That section is a member of a comdat group
COMDAT group section [  206] `.group' [_ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_] contains 2 sections:
   [Index]    Name
   [  837]   .text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
   [  838]   .rela.text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_base

The trouble is, you have another copy of that group in
libboost_locale.a(numeric.o)
COMDAT group section [  139] `.group' [_ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_] contains 2 sections:
   [Index]    Name
   [  535]   .text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
   [  536]   .rela.text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_base

Only one of these groups gets linked in, the first.  Since you link
libboost_locale.a before libstdc++.a you get the libboost_local.a
version, which doesn't have the alias symbols defined.  I'll note that
object files with different sets of global symbols in comdat groups is
a worry, indicating that your libboost isn't properly compatible with
your libstdc++.

I found it was possible to link the static libstdc++ just before
-lboost_locale without linker complaint (libstdc++.a will be linked
afterwards too).

powerpc64-linux-g++ -L. -Wl,-z,noexecstack -static-libgcc  -static-libstdc++ -g *.o -lvirtualization -lagtframework -lvirtualization -ldas -loracle -lgeneric -lnas -lsystemstate -lstoragemgmt -lsmartcopy -lagtframework -lagentutils -ludplinuxutils -ludpzfsutils -lpthread -lrt -Wl,-Bstatic -lACE -lssl -lcrypto -lz -lxml2 -lboost_chrono -lboost_filesystem -lstdc++ -lboost_locale -lboost_program_options -lboost_system -lboost_thread -Wl,-Bdynamic -ldl -lrt -o udsagent

-- 
Alan Modra
Australia Development Lab, IBM

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

[Brian Groose]

Thanks for the great analysis, Alan!

It sounds like I have a good workaround there by forcing -lstdc++ first there.

As I'd like to get to the bottom of this, I assume my next question
should be "why does boost have the same function that libstdc++
does?", right?  If so, I'll see if I can track one down, as it doesn't
sound like ld is doing anything unexpected here.

On Tue, Apr 23, 2019 at 6:49 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Mon, Apr 22, 2019 at 12:04:25PM -0400, Brian Groose wrote:
> > Everything can be dropped into one directory and fails to link with this
> > /PATH/TO/NEWER/G++/g++ -L. -Wl,-z,noexecstack -static-libgcc
> > -static-libstdc++ -g *.o -lvirtualization -lagtframework
> > -lvirtualization -ldas -loracle -lgeneric -lnas -lsystemstate
> > -lstoragemgmt -lsmartcopy -lagtframework -lagentutils -ludplinuxutils
> > -ludpzfsutils -lpthread -lrt -Wl,-Bstatic -lACE -lssl -lcrypto -lz
> > -lxml2 -lboost_chrono -lboost_filesystem -lboost_locale
> > -lboost_program_options -lboost_system -lboost_thread -Wl,-Bdynamic
> > -ldl -lrt -lpam -o udsagent
>
> OK, minus the -lpam I can link this and reproduce the problem here.
>
> libboost_locale.a is the culprit.
>
> The first complaint about an undefined symbol (linking with
> -Wl,--no-demangle) is
> _ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES3_S3_RSt8ios_basecT_
>
> This is actually defined in libstdc++.a(locale-inst.o) .opd section
> (it's a function descriptor) an alias for
> _ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
> with the corresponding code in section
> .text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
>
> That section is a member of a comdat group
> COMDAT group section [  206] `.group' [_ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_] contains 2 sections:
>    [Index]    Name
>    [  837]   .text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
>    [  838]   .rela.text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_base
>
> The trouble is, you have another copy of that group in
> libboost_locale.a(numeric.o)
> COMDAT group section [  139] `.group' [_ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_] contains 2 sections:
>    [Index]    Name
>    [  535]   .text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_basecT_
>    [  536]   .rela.text._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES4_S4_RSt8ios_base
>
> Only one of these groups gets linked in, the first.  Since you link
> libboost_locale.a before libstdc++.a you get the libboost_local.a
> version, which doesn't have the alias symbols defined.  I'll note that
> object files with different sets of global symbols in comdat groups is
> a worry, indicating that your libboost isn't properly compatible with
> your libstdc++.
>
> I found it was possible to link the static libstdc++ just before
> -lboost_locale without linker complaint (libstdc++.a will be linked
> afterwards too).
>
> powerpc64-linux-g++ -L. -Wl,-z,noexecstack -static-libgcc  -static-libstdc++ -g *.o -lvirtualization -lagtframework -lvirtualization -ldas -loracle -lgeneric -lnas -lsystemstate -lstoragemgmt -lsmartcopy -lagtframework -lagentutils -ludplinuxutils -ludpzfsutils -lpthread -lrt -Wl,-Bstatic -lACE -lssl -lcrypto -lz -lxml2 -lboost_chrono -lboost_filesystem -lstdc++ -lboost_locale -lboost_program_options -lboost_system -lboost_thread -Wl,-Bdynamic -ldl -lrt -o udsagent
>
> --
> Alan Modra
> Australia Development Lab, IBM

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

[Alan Modra]

On Tue, Apr 23, 2019 at 04:33:43PM -0400, Brian Groose wrote:
> As I'd like to get to the bottom of this, I assume my next question
> should be "why does boost have the same function that libstdc++
> does?", right?

Yes, and if for a good reason, why not exactly the same.

-- 
Alan Modra
Australia Development Lab, IBM