X-Spam-Check-By: sourceware.org
Message-ID: <4676F454.5713330@dessent.net>
Date: Mon, 18 Jun 2007 14:08:36 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Some notes on building gcc-4.3.0
References: <466F9B52 DOT 1000709 AT cwilson DOT fastmail DOT fm> <4672C1F4 DOT 6010306 AT users DOT sourceforge DOT net> <46736405 DOT 2010303 AT cwilson DOT fastmail DOT fm> <4673E461 DOT 80960A59 AT dessent DOT net> <f56pbr$mql$1 AT sea DOT gmane DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/