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.
