* Linux ppc64 - compatibility-ldbl.o can't find std::num_put
@ 2019-04-10 16:53 Brian Groose
2019-04-13 2:57 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Brian Groose @ 2019-04-10 16:53 UTC (permalink / raw)
To: binutils
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put
2019-04-10 16:53 Linux ppc64 - compatibility-ldbl.o can't find std::num_put Brian Groose
@ 2019-04-13 2:57 ` Alan Modra
2019-04-13 17:32 ` Brian Groose
0 siblings, 1 reply; 8+ messages in thread
From: Alan Modra @ 2019-04-13 2:57 UTC (permalink / raw)
To: Brian Groose; +Cc: binutils
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put
2019-04-13 2:57 ` Alan Modra
@ 2019-04-13 17:32 ` Brian Groose
2019-04-14 23:16 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Brian Groose @ 2019-04-13 17:32 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put
2019-04-13 17:32 ` Brian Groose
@ 2019-04-14 23:16 ` Alan Modra
2019-04-15 15:16 ` Brian Groose
0 siblings, 1 reply; 8+ messages in thread
From: Alan Modra @ 2019-04-14 23:16 UTC (permalink / raw)
To: Brian Groose; +Cc: binutils
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put
2019-04-14 23:16 ` Alan Modra
@ 2019-04-15 15:16 ` Brian Groose
[not found] ` <20190416102257.GR14424@bubble.grove.modra.org>
0 siblings, 1 reply; 8+ messages in thread
From: Brian Groose @ 2019-04-15 15:16 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-04-24 13:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-10 16:53 Linux ppc64 - compatibility-ldbl.o can't find std::num_put Brian Groose
2019-04-13 2:57 ` Alan Modra
2019-04-13 17:32 ` Brian Groose
2019-04-14 23:16 ` Alan Modra
2019-04-15 15:16 ` Brian Groose
[not found] ` <20190416102257.GR14424@bubble.grove.modra.org>
[not found] ` <CAKMEP22JpJ2kZudtYCX-zLkGwDcsNcDcLPQZSnSAW4LBzObc3Q@mail.gmail.com>
[not found] ` <20190417003822.GZ14424@bubble.grove.modra.org>
[not found] ` <CAKMEP22iLBSHNBYjhSQM7MubcjQQ0vaJo4cru0sP+3Y6y-ZOdA@mail.gmail.com>
[not found] ` <CAKMEP22ci3Wu-OVhkMMb91fhxD23WX4rEEv9YohDHg6PxozurQ@mail.gmail.com>
2019-04-23 10:49 ` Alan Modra
2019-04-23 20:33 ` Brian Groose
2019-04-24 13:54 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).