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.

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

mingw-runtime...sure, that could probably be "relocated" without
trouble.  I don't think the "regular" cygwin gcc should care about that.

> mingw and w32api into standard
> locations.  That was part of the reason for getting rid of -mno-cygwin.


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