Charles Wilson wrote: > (2) Curious: does using a -dw2 compiler work when linking against code > that was compiled using an sjlj compiler? e.g. in a static library or > in a shared library?
I suppose this all depends on the nature of the code. If you can get yourself into a situation where the Dwarf unwinder encounters a frame in the sjlj library when processing a throw, then it's got no choice but to terminate with an abort. > Like cygwin1.dll? > > Or, because cygwin1.dll exposes a very C-ish (not C++-ish) interface, > then what about other C++ libraries, such as xerces or ncurses++? I don't think this matters so much for Cygwin as it's built entirely with -fno-exceptions -fno-rtti and so it's EH-agnostic. But for existing C++ libraries I think the EH flavor may be a moot point because of another issue: if we go with shared libstdc++ (and to me everything indicates that we will need this for both performance and correctness) then those libraries will have to be rebuilt anyway even if EH doesn't change. Consider what happens if you have an existing C++ library built as a DLL with current g++ 3.4. Since the only option right now is static libstdc++, that means any libstdc++ code that the library needs is statically included in the DLL. Now consider that we get a g++ 4.3 that has a shared libstdc++, and you use that to create an .exe that links to that existing C++ library. Now you have (old library + its statically linked libstdc++ 3.4) linked to (new app + shared libstdc++ 4.x) which results in two different simultaneous versions of libstdc++ being present at runtime which sounds like a recipe for true horror if e.g. the main module and the library need to pass around std::string datastructures or whatnot. Once we pull the trigger on shared target libs I think there will be a period of instability during which we have to work out all these nightmares of libgcc and libstdc++ incompatibilities, but it's really something that we just have to grin and bear. Also this isn't exactly a new condition per se: remember that g++ changed ABIs between 3.3 and 3.4, so any C++ libraries would have had to have been rebuilt when we made that transition as well. I don't remember a whole lot of fuss back then (but maybe I just wasn't paying very close attention) which leads me to think that the number of actual C++ libraries in the distro may be small. Or maybe we just have a lot more packages today than we did then so it's an invalid comparison. Brian
