From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1107 invoked by alias); 24 Feb 2009 16:12:43 -0000 Received: (qmail 1089 invoked by uid 22791); 24 Feb 2009 16:12:42 -0000 X-Spam-Check-By: sourceware.org Received: from pool-173-76-42-111.bstnma.fios.verizon.net (HELO cgf.cx) (173.76.42.111) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Feb 2009 16:12:36 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 6903413C026 for ; Tue, 24 Feb 2009 11:12:26 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id 2B4442B35E; Tue, 24 Feb 2009 11:12:26 -0500 (EST) Date: Tue, 24 Feb 2009 16:12:00 -0000 From: Christopher Faylor To: cygwin-apps@cygwin.com Subject: Re: GCC4 status. Message-ID: <20090224161225.GA16741@ednor.casa.cgf.cx> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <49A36143.50305@gmail.com> <49A37084.3090708@users.sourceforge.net> <49A37423.4050006@gmail.com> <49A38010.80906@cwilson.fastmail.fm> <49A3EC2B.5040607@gmail.com> <49A40450.8020107@cwilson.fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A40450.8020107@cwilson.fastmail.fm> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2009-02/txt/msg00134.txt.bz2 On Tue, Feb 24, 2009 at 09:29:36AM -0500, Charles Wilson wrote: >Dave Korn wrote: >> Well, I'm as allergic as cgf seems to be to the idea of having >> duplicated-and-potentially-inconsistent sets of the same files around the >> place, > >D'oh. I was forgetting that the cross compiler would be a cygwin app. >For some reason I was thinking that it wouldn't be able to understand >symlinks, so it needed actual files (copies) for its "relocated" w32api >and mingw-runtime headers/libs. Then again, the native cygwin compiler >is obviously a cygwin app, so it's just a reasonable to put the "real" >files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate >/usr/[include|lib]/[w32api] with symlinks. > >For mingw-runtime, the only reason not to completely relocate /ITS/ >headers, libs, and objects (but not mingwm10.dll and docs) is backwards >compatibility with existing -mno-cygwin-capable compilers, or if Dave >doesn't want to respin gcc-3.4.4-999 to look in the new location. The >new cygwin-only gcc shouldn't care about mingw-runtime at all. > >To close out the "relocate vs. copy vs. symlink" subthread: I was also >thinking of the "two copies" problem from the w32api-maintainer's >perspective. I don't consider the following: > $ configure --prefix=/usr/i686-pc-mingw32 \ > --includedir=${prefix}/include/w32api \ > --libdir=${prefix}/lib/w32api > $ make && make install DESTDIR=/tmp/foo > ... > $ configure --prefix=/usr \ > --includedir=${prefix}/include/w32api \ > --libdir=${prefix}/lib/w32api > $ make && make install DESTDIR=/tmp/foo > ... > $ make-pkg w32api /tmp/foo/ > or > $ make-pkg w32api /tmp/foo/usr > $ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32 >to be very prone to inconsistency. Heck, the pkg-build script could >even include a giant "diff -urN" sanity check. You're not thinking about this from the proper perspective if you think that the package maintainer is the one who would have problems with two copies. cgf