This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question on DSO and visibility


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.

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

> 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
with --with-default-libstdcxx-abi=gcc4-compatible)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]