Mail Archives: cygwin/2007/06/18/17:09:01
Shankar Unni wrote:
> You already see the effects of this in the Linux world, with the more
> recent distributions having to ship a set of compat_libgcc_blah packages
> for each major (ABI-incompatible) previous release going back (they're
> on 4.1/4.2 these days, and there's one for 3.3 and one for 2.9).
It's just like any other library that is used by a lot of programs and
has had a history of ABI changes.
> And most commercial/non-free software shipped on Linux (e.g. Oracle,
> Java, ..) just states explicitly which packages they depend on.
Well of course, any functioning package management system requires this.
> So if I may offer a blueprint going forwards:
>
> * introduce a libgcc_something package containing the latest DLLs/.so's,
> and include it in the Base package.
>
> * later, if these are ever incompatibly ABI-rev'ed, switch the default
> distribution to the new version, and introduce a compat-libgcc-* package
> for the old version (which preserves their filename), and include that
> in the Libs package.
I have no doubt that we won't encounter any problems getting this right
on the Cygwin packaging end. That wasn't my concern.
What worries me is that there is no "packaging system" at all for other
users of gcc on Win32. If you want to distribute your MinGW compiled
binary most of the time you just make a zip file of the required parts,
including any DLLs, or maybe you use NSIS, MSI, whatever installer
system of choice. The problem comes when one of these packages does a
jerky thing like install a libgcc_s into the system32 dir. The regular
user of Cygwin will be affected by these jerky installers if they put
the file in system32 or if they put the file in their own install dir
and add that install dir to the PATH.
Now, I think we are mostly saved by the fact that traditionally Cygwin
and MinGW libraries have always been distinguished by the "cyg" vs "lib"
naming prefix, so if we continue with that for libgcc we will be mostly
immune to idiot installers. But that doesn't do anything to help the
MinGW guys, who I guess will have to rely on just having some form of
version number as part of the DLL file name so that at least an ancient
libgcc never overwrites a newer one because somebody installed
DancingPonyScreenSaver v1.2 written by a clueless moron that drops its
junk in \system32.
But at the moment, neither of those two things (versioning and
lib-prefix name) is handled by the gcc build system, so right now it's
like driving in a car with no seatbelts and razor blades in the
dashboard.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -