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?


Corinna Vinschen wrote:
> I'm not sure there is really such a interdependency.  Shouldn't the
> static libgcc3 functions and the new shared gcc4 libgcc functions
> co-exist and not notice each other?

Unless they are supposed to both update the same data structure (e.g.
unwinding code) but have different ideas about the contents of that
structure.  For instance, the exceptions-across-dll-boundaries hack in
gcc3 modifies some structure used by libgcc, by adding a field which
gcc4's libgcc doesn't know about, IIRC.

>>If we don't do an ABI bump, then we break all client packages
>> until they are rebuilt == flag day.
>
> libintl8-1?

I'm not sure what you mean by this.  libintl8 was my shorthand for the
DLL named "cygintl-8.dll".  That name is hardcoded in all clients that
use the DLL, regardless of the name of the tarball in which the DLL is
delivered by the cygwin packaging system.  If by libintl8-1 you mean
"cygintl-8-1.dll" that's a name change if not, precisely, a version
number "bump" -- but it is a DLL name change that requires HEAVY
patching to make that happen, esp. with libtool.  It's only slightly
different than a "typical" ABI bump to e.g. cygintl-9.dll in that it
"saves" the cygintl-9.dll "slot" for the next real upstream ABI change. 
Thus, the "maintain patches in perpetuity" problem goes
away...eventually (a year? two?).  Not sure if the pain is worth it,
though, because now "libintl.dll.a" (basename "intl") and "libintl.a"
(basename "intl") are NOT mapped to cygintl-N.dll (basename "intl" +
vernum) but instead to "cygintl-8-N.dll" (basename "intl-8" + vernuum). 
That's a fairly icky "temporary" (a year? two?) patch.  Not so bad for
gettext/libintl, but unweildy for, say, gtk+.

> I understand that there is trouble along the way, but, actually, do we
> really have a choice?  As you write in your other mail, we're in a
> transition period.  We're transitioning in at least two ways, a very
> new Cygwin and a very new gcc.  We will have to drag it along and
> we can't force other maintainers to do a JIT job.  At the very least,
> if some packages break, the maintainer will probably notice (or be
> noticed) and provide a new package within a couple of days.

So, if I understand correctly, you're (gently) advocating

#1) don't bump the ABI number of DLLs just because of cygwin-1.7/gcc4
(of course, if there is some OTHER reason that the ABI changes, then the
DLL number SHOULD be bumped).
#2) hope that nothing breaks
#3) if some app does break, it's up to that app's maintainer to rebuild
as needed, NOT the DLL maintainer to ensure backwards compatibility,
even though per #1 he has re-used the existing DLL number.
#4) BUT no need to coordinate all of these rebuilds -- if any are
required -- on some sort of official flag day

I could go along with that, with the understanding that this means the
official cygwin-1.7 rollout /may/ be a bit more bumpy that we had
previously expected.

#a) While the more active maintainers are in the process of rebuilding
packages (esp. DLL packages) with gcc4 -- whether before the official
cygwin-1.7 release or after -- we /may/ see client app breakages.
Hopefully, if they occur at all, they will be brief -- and even the less
active maintainers will be able to react quickly /enough/ to minimize
the disruption per #3.

#b) For privately compiled clients of official DLLs whose ABI (may)
change due to these transition issues but whose cyg*-N.dll name has not
been bumped per #1 above, those private clients /may/ break. And people
will complain, and we'll tell 'em to recompile. WJM, after all.

--
Chuck


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