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?
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?
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 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 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 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
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]
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