This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [RFC] ABI bump for building with gcc4 ?
-----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-----