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 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


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