From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18095 invoked by alias); 24 Feb 2009 16:35:39 -0000 Received: (qmail 18083 invoked by uid 22791); 24 Feb 2009 16:35:37 -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:35:31 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id ED7B513C026 for ; Tue, 24 Feb 2009 11:35:18 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id E85CA2B35E; Tue, 24 Feb 2009 11:35:18 -0500 (EST) Date: Tue, 24 Feb 2009 16:35:00 -0000 From: Christopher Faylor To: cygwin-apps@cygwin.com Subject: Re: GCC4 status. Message-ID: <20090224163518.GB16741@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> <20090224051757.GA15043@ednor.casa.cgf.cx> <49A38553.2080801@cwilson.fastmail.fm> <20090224091451.GA13626@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224091451.GA13626@calimero.vinschen.de> 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/msg00135.txt.bz2 On Tue, Feb 24, 2009 at 10:14:51AM +0100, Corinna Vinschen wrote: >On Feb 24 00:27, Charles Wilson wrote: >> Christopher Faylor wrote: >> > On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote: >> >> Dave Korn wrote: >> >>> it's going to be a fairly non-standard >> >>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's >> >>> going to look for headers and libs directly where they live under the native >> >>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api, >> >>> and it's going to use the native 'as' and 'ld'. So it's going to be an ugly >> >>> hybrid beast.... >> >> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just >> >> because we don't want two copies of w32api and mingw-runtime, or a >> >> cross-ld/cross-as? >> >> >> >> I think the maintenance headaches associated with an "ugly hybrid beast" >> >> outweigh those other, tiny, costs... >> > >> > I agree. I think we should relocate >> >> relocate? But the regular cygwin gcc needs at least w32api, and that >> location is hardcoded in its specs file. Which means that relocate >> implies -> respin gcc-3.4.4-999, and respin gcc-4.2.3. And it doesn't >> really make sense for the cygwin-gcc specs to specify "always look in >> /usr/i686-pc-mingw32/include/[w32api]". Whuh, huh? *-mingw32? >> >> It makes more sense to me that we have two different w32api packages: >> the "regular" one that installs into /usr/[include|lib]/w32api, and a >> mingw-cross-w32api that installs into >> /usr/${mingw-triple}/[include|lib]/[w32api]. > >IMO it would be much easier to keep mingw and w32api in place and just >create matching symlinks in /usr/i686-pc-mingw32. This way you can >create a standard compiler *and* keep the include and lib files in >place. We can't move all of it out of the way anyway. We need at least >the mingw DLL in /bin since some Cygwin tools rely on it. Maybe I'm missing something but I just checked every executable in my bin area and I didn't find any that relied on a mingw DLL. >w32api headers and linking against Windows libs in Cygwin applications >might not be very POSIX compliant, but is necessary. Every Cygwin >application you link must be linked against kernel32.dll and friends. That's why I talked about making selective symlinks into /usr/lib. Maybe, to be kind, we could create a /usr/mingw directory so that people could add -L/usr/mingw/lib to their link lines rather than -L/usr/i686-pc-mingw/lib . >There's also still a lot of Windows functionality we can't cover in >Cygwin. USB access as in libusb-win32 comes to mind. I don't see what a separate package has to do with anything. I'm just talking about making sure that the mingw packages live where they should rather than where they have been historically - and I'm actually to blame for some of the poor choices for these directories. I wouldn't normally suggest such a radical change but since we're talking about releasing new versions of gcc this seems like a good time to clean things up. cgf