-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Charles Wilson wrote: > True. Until all -- or almost all -- of the distro is *slowly* rebuilt > using gcc4 -shared-libgcc. The difference is, it CAN be slow, and > needn't happen all at once on some "flag day".
I'm arguing that perhaps it should, just as other distros surely handled this sort of transition. > What do we tell our users? "Well, with (new version) gtkmm, you have to > have gtk2-x11-runtime-2.6.10-17 or newer even though the internal DLLs > have the same name, because, well, we deliberately broke the ABI on C > libraries without updating the DLL number because it was too hard. Just > upgrade." No, we rebuild bottom up, and those old libraries will no longer be available for gcc4. > But it's really ugly, and very surprising to end users. Sure, WJM and > all that. But basically you're back to a "flag day" recompile everything > all at once issue. :-( Which is what I'm proposing. > 3) -shared-libgcc vs. -static-libgcc. I was ALSO assuming that > "recompile with gcc4" was semantically equivalent to "and link with the > shared libgcc". I considered this to be a significant -- possibly ABI > breaking [*] -- change, that in itself would force an ABI version bump. > Do we really want to mix DLLs and apps where some use the shared libgcc > and others directly contain pieces of the gcc3 static one (with possibly > different internals)? I agree that we don't want to mix these. Everything should be gcc4 with - -shared-libgcc (which I think should be the default anyway). > Because this is a major change *for us* -- fraught with the possibility > of incompat probs -- we have two choices: > > A) version bump all shared libs; newly compiled code (with dw2, gcc4, > -shared-libgcc) will use new, compatible (dw2, gcc4, -shared-libgcc) > libraries. Old code (gcc3) will continue to use old libs (gcc3). > > B) FLAG day. Hey all you maintainers, you have 2 weeks to rebuild > everything you maintain. Or bad things will happen to users and it will > be your fault, you sluggard. (A) is simply unmaintainable system-wide. B++. > Guess which way I lean? Hell, it took me a week just to work out the > issues with ncurses, and that was *without* switching compilers. Once again we have different outlooks. What a surprise. :-) > (Side note: Dave, what are your plans for the gcc4 mingw cross compiler? > sjlj or dw2? Or maybe just take the mingw.org src tarball and build it > using "their" cross scripts > http://www.mingw.org/wiki/LinuxCrossMinGW > adapted for our packaging system? etc) The mingw cross compiler needs to be compatible with whatever mingw itself is producing, otherwise there isn't much of a point. > Well, jpeg is just dumb. It's not my fault they chose a silly system > for their SONAMEs. The libtool documentation (and a little thought) > will tell you, do NOT try to make your library SONAME match your package > version. They did. Oops. While that may be true in general, essentially they are saying that each version of jpeg is ABI incompatible with the next (when/if there will ever be a next release!). > My plan for libjpeg was to bump the DLL vernum to 100. And then just > increment by one as needed. Then *cygwin's* dll number would, in fact, > be unrelated to the package version, as God and libtool intended. The other issue with jpeg in particular is the ljpeg patches. These are API incompatible with the stock jpeg, and a number of packages won't compile OOTB as they should because of it. I would ask that the ljpeg patch be dropped. > Yes. I realize that -- and it's a big issue for large distributions like > your GNOME and KDE ports. True. But you haven't answered the parallel-installability issue. How do you suggest that be handled? > So you agree that the gcc3-->gcc4 transition presents possible > compatibility issues? That new stuff WILL be incompatible with old > stuff (e.g. ABI bump vs FLAG day)? Then why did you bring up linux: > "They didn't need to bump their ABIs" -- of course not. They had no > compatibility issues to worry about. We do -- Are you sure, what about e.g.: http://lwn.net/Articles/160330/ Debian modified the *package* names, but not the actual library names. Of course, they seem to allow for a given file to be owned by more than one package, something that setup.exe can't do, so we're left with a flag day recompile. > Uhm, remind me again why the next release of cygwin is called cygwin-1.7 > and contains cygwin1.dll, and not cygwin-2.0 with cygwin2.dll? :-) Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm6oH0ACgkQpiWmPGlmQSMYJACfQnDWyFcbdF/IOWLPs/U5mudl rDMAn2/kY6CYO3lhNV9Ld8aQwiu8kd6p =YHIk -----END PGP SIGNATURE-----