On 24 March 2016 at 17:37, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 24 March 2016 at 17:29, Jeffrey Walton <noloader@xxxxxxxxx> wrote: >> On Thu, Mar 24, 2016 at 1:02 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >>> On 24 March 2016 at 16:43, Jeffrey Walton wrote: >>>> There are lots of folks who have experienced the issue; check out >>>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@xxxxxxxxxxxxxxxx. >>>> Debian happened to say "f**k it, we'll just recompile everything under >>>> the new ABI and be done with it". But they experienced the corner-case >>>> issues too. I don't know why they did not consult with the GCC folks. >>> >>> They did. Rebuilding everything is the right choice. >> >> It was an incomplete remediation. Debian still has open bugs because >> of it, and we are fielding reports because of it. >> >>>> This step was not obvious to me at all. I don't ever recall having to >>>> define a library macro for a library: >>>> >>>> $ g++ -D_GLIBCXX_USE_CXX11_ABI=0 -c test.cxx -o test-v1.o >>>> $ g++ -D_GLIBCXX_USE_CXX11_ABI=1 -c test.cxx -o test-v2.o >>>> >>>> Naively, because of the blog post on the coexistent implementations, I >>>> was looking for an option like -dual-abi to do it for me. >>> >>> Which is a leap that doesn't in any way follow from a literal reading >>> of the blog post! >> >> Right. We've had similar on other platforms for years and even on >> Linux. For example, with Apple, we can build fat binaries. Even the >> kernel has FatELF (http://lwn.net/Articles/359070/). >> >> This situation seems like a perfect application of the technologies, >> but it seems to be missing from the solution. Hence the reason I >> refrained from the leap, and asked what to do/how do I do it. > > I've written up the basic steps of how to do what I really, really > suggest you do not try to do at http://kayari.org/cxx/dualabi.html > > The last section explains why a simple compiler switch probably won't > work: most code will need non-trivial refactoring to make it work, > which a compiler could not do on the fly if you simply provide a > command-line option. Fat binaries are not analogous, they contain two entirely different things in one binary, with almost nothing in common between them. That is completely different from the situation with libstdc++.so's "dual ABI", where 90% or more of the code is common to the two ABIs, and only the parts that differ need to be compiled twice.
