This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] ready for cygport to default to gcc4?


cgf wrote:
> As one of the maintainers who falls in the sporadically active category
> I really don't relish the thought of a flag day version bump. 

Me neither.  I'm STILL struggling to work my way through recompiling
"my" packages for cygwin-1.7 *without* any attempts towards gcc4.

But the alternatives are also bad, as I mentioned in my reply to
Corinna.

> I wasn't
> paying really close attention but I seem to recall Yaakov mentioning
> that other distros didn't require a version bump when moving to gcc4 so
> I would rather not do this.

And I think I showed that Linux != cygwin in this regard:
http://cygwin.com/ml/cygwin-apps/2009-03/msg00038.html

Short version:
1) The Linuxes were already all using -shared-libgcc by default. We're
transitioning.
2) The Linuxes were already all using DW2 EH (which affects libgcc);
We're transitioning.
3) cygwin-gcc3 uses an internal hack to the ABI of libgcc (not libstdc++
or libsupc++) to handle the C++ exceptions-across-DLL-boundaries issue.
cygwin-gcc4 does not -- this changes libgcc. So that's another ABI
difference, which is going to affect every DLL and EXE compiled with
gcc4.
4) C++ only: even though the official gcc C++ ABI did not change between
3.4.x and 4.x (I think), cygwin's absolutely did: cygwin-g++-3 used a
patch to address the PR24196 empty-string issue. cygwin-g++-4 uses
--enable-fully-dynamic-string. That's a C++ ABI change. Than, of course,
there's the dw2/sjlj eh thing, which obviously affects the C++ ABI even
more than it does the C ABI.

Basically, I believe -- but do not absolutely *know* for sure -- that
there are enough ABI-breaking changes in the transition from

gcc-3/static-libgcc/sjlj-eh to gcc-4/shared-libgcc/dw2-eh (not to
mention a few C++-specific bugaboos)

that we *will* discover, somewhere along the way, that some (or many, or
all) DLLs built with gcc4 will break old EXEs built with gcc3, unless
(a) the DLLs are ABI-bumped, or (b) the EXEs are recompiled. 
Unfortunately, you can't discover this before the fact. If you don't
bump the ABI -- to accommodate Yaakov's concerns about large package
suites -- then by the time you discover a problem it's too late.  If you
revert that DLL edition, and rebuild a ABI-bumped release for it, then
you break OTHER apps that WERE rebuilt against the non-version-bumped
but now-withdrawn edition of that DLL.

> And, as Corinna mentions, it would be very difficult to pull off anyway.

Yes, it would be. But we have done it before: when 1.5.0/1/2 was
released, and we were moving toward 64bit/largefile support. Granted,
the cygwin distribution and # of maintainers is much larger now...

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]