This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC4 status.


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.  And using
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.
There's also still a lot of Windows functionality we can't cover in
Cygwin.  USB access as in libusb-win32 comes to mind.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]