This is the mail archive of the
mailing list for the Cygwin project.
Re: gcc 4.x for Cygwin?
- From: Brian Dessent <brian at dessent dot net>
- To: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- Cc: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
- Date: Wed, 05 Dec 2007 22:30:24 -0800
- Subject: Re: gcc 4.x for Cygwin?
- References: <20071127173815.GA30894@calimero.vinschen.de> <20071129170838.GA24864@calimero.vinschen.de> <041b01c83686$3253f620$2e08a8c0@CAM.ARTIMI.COM> <47578B14.firstname.lastname@example.org>
- Reply-to: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
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.