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 project twice. 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 worth it. > 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. 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!
