Re: gcc 4.x for Cygwin?
Dave Korn wrote: Option 2. I don't see there's any other sensible choice. Ultimately I guess I'd like to figure out a way to make unwinding and exceptions interwork with the native SEH to address the potential downside. (1) There was supposed to be a Google Summer of Code project addressing SEH in gcc. It was listed as an accepted project here: http://gcc.gnu.org/wiki/SummerOfCode But nothing seems to have actually happened, to judge by http://code.google.com/soc/2007/gcc/about.html (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? 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++? If the answers to the questions above are bad, then is the (official, non-experimental) release of a gcc-4.x-dw2 compiler something that should wait until cygwin-1.7, with all of the backward-incompatibility he** implied by bad answers? -- Chuck P.S. sorry for the delay in responding. I've been effectively offline for several weeks (work+family).
Re: gcc 4.x for Cygwin?
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
RE: gcc 4.x for Cygwin?
On 29 November 2007 17:09, Corinna Vinschen wrote: On Nov 27 18:38, Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Any opinion from the gcc maintainer? Option 2. I don't see there's any other sensible choice. Ultimately I guess I'd like to figure out a way to make unwinding and exceptions interwork with the native SEH to address the potential downside. cheers, DaveK -- Can't think of a witty .sigline today
RE: gcc 4.x for Cygwin?
On 29 November 2007 17:09, Corinna Vinschen wrote: Dave? Any opinion from the gcc maintainer? My opinion is I'll have time to catch up on this thread at the weekend but I've been in crisis-release-deadline-firefighting mode all week and really need to get a night with more than three hours' sleep first. Sorry for not being more responsive. cheers, DaveKzzsnorkgRMMGF I WAS JUST RESTING MY EYES HONEST! -- Can't think of a witty .sigline today
Re: gcc 4.x for Cygwin?
On Nov 29 17:15, Dave Korn wrote: On 29 November 2007 17:09, Corinna Vinschen wrote: Dave? Any opinion from the gcc maintainer? My opinion is I'll have time to catch up on this thread at the weekend but I've been in crisis-release-deadline-firefighting mode all week and really need to get a night with more than three hours' sleep first. Sorry for not being more responsive. Ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
On Nov 27 18:38, Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Any opinion from the gcc maintainer? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
On Tue, 27 Nov 2007 18:38:15 +0100 FWIW, my 2 cents: Corinna Vinschen wrote: As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? I am also inclined towards preferring option 2. In my case, I have no interest in the ada or java compiler components, and as yet use cygwin for GUI work very little or nil. From what I understand of the issues, dwarf2 exception handling is the far cleaner approach, contrasted with sjlj. The jump from release 3 to release 4 GCC seems like the right time to make a switch that might confound some user's uninformed expectations (i.e. What? You mean I cannot just switch from gcc-3.x.x to gcc-4.x.x on Cygwin without knowing about ramifications?). If the switch isn't made at the 3-4 transition boundary it becomes that much less easily remembered and communicated to users as they come along. I'm also in agreement with the notion expressed by Brian Dessent (in [EMAIL PROTECTED]): [...] switch to DW2 exception handling as default for all of Cygwin and then think about providing a fallback/parallel installation sjlj package for anyone doing Win32 GUI stuff. Not that I suggest it would be a trivial effort for someone to support such a parallel package; but if someone was *willing* to do so it seems like a solution that would provide options valuable to some Cygwin users. Regards. -- All unaccompanied children will be given espresso and a free kitten. -- Find out how you can get spam free email. http://www.bluebottle.com/tag/3
gcc 4.x for Cygwin?
Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
Corinna Vinschen wrote:
Did anything happen in the gcc 4.x world which would help us to get a
gcc 4.x for Cygwin at one point? Are some of the problems reported in
http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the
meantime?
Mainline gcc still won't build shared target libraries on Win32, which
means exceptions across DLLs is still broken. Grumble. Danny's 4.2
MinGW test release has shared libgcc and shared libstdc++ but it was
done by hand by him, by some ugly kind of extract objects from lib.a
and relink dll thing. It would be great to get this finally solved
upstream so we can stop suffering all the negative consequences that
static target libs bring -- static libgcj for example makes the Java
exceptions stuff really broken, from what I understand, making it nearly
unusable.
MinGW has it doubly bad here in that it's hard for them to make shared
libgcc default because everyone using MinGW is all about making
standalone binaries and hate having to distribute some libgcc_s.dll
file. However for us, there is no good reason why we shouldn't make
shared {libgcc,libgfortran,libstdc++,libgomp} the default since we have
a packaging system. This will make it a little easier since the specs
file is already designed to work this way, having e.g. a -static-libgcc
override for when you need it, but not the other way around.
I think it would be prudent just to ignore ada and java for the time
being; there's no reason for them to hold up C/C++/fortran. Danny's
MinGW 4.2 preview omitted java but not ada. They could be filled in
later, if for example somebody interested in shoring up upstream for
Win32 gets on the ball.
I believe that dllimport on forward declarations of classes has been
fixed; there was a major rewrite of the dllimport/export handling code.
The DW2/SJLJ thing still looms of course. I'd be tempted to say we
switch to DW2 exception handling as default for all of Cygwin and then
think about providing a fallback/parallel installation sjlj package for
anyone doing Win32 GUI stuff. This is kinda what Danny did as well.
The final (somewhat embarrassing) thing is that the last time I tried
building Cygwin itself with gcc 4.x it was impossible to get something
that didn't crash hard at startup due to aliasing booboos, even with
-fno-strict-aliasing. But that may have changed, I haven't tried in a
long while.
Brian
Re: gcc 4.x for Cygwin?
Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? FWIW, I would opt for dwarf2 Corinna -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) [EMAIL PROTECTED]
