This is the mail archive of the
mailing list for the GCC project.
Re: Question on DSO and visibility
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paul Smith <paul at mad-scientist dot net>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 14 Sep 2016 10:13:32 +0100
- Subject: Re: Question on DSO and visibility
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
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.
> I have users who will be using my library who are also writing C++ code
> and they will be using older versions of GCC (I build my own GCC and I
> use a specific sysroot for an older version of libc etc. so I know my
> code will run properly on their system: they'll use their distribution's
> version of GCC).
> What I was thinking of doing was this:
> 1. Link my DSO with -static-libstdc++ and -static-libgcc
> 2. Ensure that no STL typed objects are passed across the ABI between my
> library and its callers; also that no memory I allocate is freed by
> the user and no memory the user allocates is freed by me (my library
> also runs on Windows as a DLL so I already have this restriction).
On GNU/Linux there's no reason for the restriction on allocation,
there's only a single malloc. You might need to do that for Windows,
but not GNU/Linux.
> 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).
> Is this plan sufficient to allow people to link with my library and not
> have their version of GCC's libstdc++.so interfere with my library's
> version, so the different ABI's can coexist in the same program without
> interfering with each other?
The different ABIs coexist automatically. Affected symbols mangle
differently so they don't collide.
> 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
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