From: Jonathan Wakely <jwakely@redhat.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix gnu-versioned-namespace build
Date: Wed, 11 Dec 2019 16:48:00 -0000 [thread overview]
Message-ID: <20191211164820.GX11522@redhat.com> (raw)
In-Reply-To: <16fe9ee4-310a-d8d1-d581-4afdf4590d9a@gmail.com>
On 11/12/19 08:29 +0100, François Dumont wrote:
>I plan to commit this tomorrow.
>
>Note that rather than just adding the missing
>_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace
>usage outside std namespace. Let me know if it was intentional.
>
> * src/c++11/random.cc: Add _GLIBCXX_BEGIN_NAMESPACE_VERSION and
> _GLIBCXX_END_NAMESPACE_VERSION. Move anonymous namespace outside std
> namespace.
>
>Tested under Linux x86_64 normal/debug/versioned namespace modes.
>
>There are still tests failing in versioned namespace, more patches to come.
One of them fails like this:
/home/jwakely/src/gcc/buildso8/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:134: undefined reference to `_ZNSt3__87codecvtIDsDu11__mbstate_tE2idE'
For some reason some of the char8_t instantiations are not exported
from the libstdc++.so.8.0.0 shared library:
00000000000aaad0 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE10do_unshiftERS1_PDuS4_RS4_
00000000000aaa80 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE11do_encodingEv
00000000000aaaa0 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE13do_max_lengthEv
00000000000aaa90 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE16do_always_noconvEv
00000000000ab870 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE5do_inERS1_PKDuS5_RS5_PDiS7_RS7_
00000000000abc50 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE6do_outERS1_PKDiS5_RS5_PDuS7_RS7_
00000000000ab810 t _ZNKSt3__87codecvtIDiDu11__mbstate_tE9do_lengthERS1_PKDuS5_m
00000000000aaac0 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE10do_unshiftERS1_PDuS4_RS4_
00000000000aaa80 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE11do_encodingEv
00000000000aaaa0 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE13do_max_lengthEv
00000000000aaa90 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE16do_always_noconvEv
00000000000abd40 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE5do_inERS1_PKDuS5_RS5_PDsS7_RS7_
00000000000ab990 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE6do_outERS1_PKDsS5_RS5_PDuS7_RS7_
00000000000ab900 t _ZNKSt3__87codecvtIDsDu11__mbstate_tE9do_lengthERS1_PKDuS5_m
0000000000157a00 b _ZNSt3__87codecvtIDiDu11__mbstate_tE2idE
00000000000ab270 t _ZNSt3__87codecvtIDiDu11__mbstate_tED0Ev
00000000000ab130 t _ZNSt3__87codecvtIDiDu11__mbstate_tED1Ev
00000000000ab130 t _ZNSt3__87codecvtIDiDu11__mbstate_tED2Ev
0000000000157a08 b _ZNSt3__87codecvtIDsDu11__mbstate_tE2idE
00000000000ab250 t _ZNSt3__87codecvtIDsDu11__mbstate_tED0Ev
00000000000ab110 t _ZNSt3__87codecvtIDsDu11__mbstate_tED1Ev
00000000000ab110 t _ZNSt3__87codecvtIDsDu11__mbstate_tED2Ev
We should be able to add them manually to the
config/abi/pre/gnu-versioned-namespace.ver script, but that shouldn't
be necessary.
I think the problem is that the binutils demangler doesn't know how to
demangle char8_t symbols, so this fails to match them:
GLIBCXX_8.0 {
global:
# Names inside the 'extern' block are demangled names.
extern "C++"
{
std::*;
std::__8::*;
std::random_device::*
};
I'm using binutils-2.31.1-36.fc30.x86_64 but it looks like
binutils-2.32-30.fc31.x86_64 also can't demangle those symbols.
next prev parent reply other threads:[~2019-12-11 16:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 7:29 François Dumont
2019-12-11 11:16 ` Jonathan Wakely
2019-12-11 11:22 ` Jonathan Wakely
2019-12-11 20:26 ` [PATCH] Fix gnu-versioned-namespace tr1 declaration François Dumont
2019-12-11 21:04 ` Jonathan Wakely
2019-12-11 20:23 ` [PATCH] Fix gnu-versioned-namespace build François Dumont
2019-12-11 20:44 ` Jonathan Wakely
2019-12-11 21:28 ` François Dumont
2019-12-11 21:33 ` Jonathan Wakely
2019-12-11 16:48 ` Jonathan Wakely [this message]
2020-10-30 12:59 François Dumont
2020-10-30 13:23 ` Jonathan Wakely
2020-10-30 13:37 ` Jonathan Wakely
2020-10-30 14:11 ` Jonathan Wakely
2020-10-30 17:51 ` François Dumont
2020-10-30 18:48 ` Jonathan Wakely
2020-10-31 17:16 ` François Dumont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191211164820.GX11522@redhat.com \
--to=jwakely@redhat.com \
--cc=frs.dumont@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).