This is the mail archive of the
mailing list for the GCC project.
Re: Question on DSO and visibility
- From: Paul Smith <paul at mad-scientist dot net>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 14 Sep 2016 10:26:31 -0400
- Subject: Re: Question on DSO and visibility
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <CAH6eHdTmQUgXwQvi99JsCnALJioeBp=KDJFY2Zb+NFLZw16LRQ@mail.gmail.com>
- Reply-to: paul at mad-scientist dot net
On Wed, 2016-09-14 at 10:13 +0100, Jonathan Wakely wrote:
> On 11 September 2016 at 22:38, Paul Smith wrote:
> > I wonder if someone can comment on this situation: I'll do some testing
> > but I likely can't test everything.
> > I'm creating DSO's for GNU/Linux with GCC 4.9.2 right now. I want to
> > upgrade to GCC 6.2.0. My code is written in C++. I'm aware of the C++
> > STL ABI break in GCC 5.x.
> Based on the solution you outlined, I'm not sure you've fully
> understood the ABI change in GCC 5.
There's little doubt you're correct about that :)
> See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
Thanks. That is relatively clear.
> > 3. Use a linker map to make all symbols in my DSO hidden except the
> > specific ones I want to be public. I use a linker map and not just
> > -fvisibility=hidden, so that all the symbols I've statically linked
> > from libstdc++.a will also be marked hidden (since libstdc++.a was
> > not compiled with -fvisibility=hidden).
> The different ABIs coexist automatically. Affected symbols mangle
> differently so they don't collide.
Aha. Yes, this is the critical point I was glossing over.
> > In other words, I can use std::basic_string and std::list in my library
> > and get the C++11 ABI from GCC 6.2 that I've statically linked, and
> > users can use std::basic_string and std::list in their code and get
> > their version of the libstdc++.so (presumably that is provided by their
> > GNU/Linux distribution) and all will work properly.
> You don't necessarily need two version of libstdc++ in the process.
> The newer libstdc++.so is compatible with the users' code.
> If all you're worried about is the ABI change then just build your
> library with _GLIBCXX_USE_CXX11_ABI defined to 0 (or build your gcc
> with --with-default-libstdcxx-abi=gcc4-compatible)
I could do that. The problem is: I actually create two different
binaries from my code: one is the shared library which users can link
and the other is a standalone application. They contain almost all the
same code (the idea is that users may want to embed the application or
run it stand-alone). I really don't want to have to compile the entire
And all things being equal, I'd like to use the newer ABI (since 99% of
my users actually use the stand-alone binary).
But maybe the complexity of both having my cake and eating it is not
> The real problem is that your library will depend on a newer libstdc++
> but that's orthogonal to the ABI changes. Statically linking it is one
> solution, deploying the newer libstdc++.so with your library is
Yes, again good point. So, as long as I don't pass objects of the
problematic types across the ABI all is fine assuming a sufficient
libstd++ library is available.
There's one question: what about exceptions? std::exception::what()
returns a const char*; I don't know if that's stored internally as a
std::string which might have problematic types. If I throw an exception
from my code (new GCC/ABI) and it's caught by the caller's code (old
GCC/ABI) is there a problem? I'm assuming this is not an issue.
One reason all this came up was that a user was linking with my shared
library and got a crash in their own code, and saw my version of
std::string in the stacktrace (because I linked libstdc++ statically)
even though my code was not involved. Even though it all was working
fine, seeing this stack trace concerned them. I was thinking that if I
ensured that my static libstdc++ was marked hidden, they would get their
own dynamically linked libstdc++ and use that from their code and I
could avoid this "appearance of impropriety".
Thanks for the response Jonathan!