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 12:27:47AM -0500, 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.

AFAIK, a normal Cygwin installation doesn't use the w32api header files
unless you're building a hybrid Cygwin/Windows program.  That is a
pretty sad beast but I guess people really do use that.  I guess we
can't think about removing -mno-win32.  A limited number of libraries
are used so it wouldn't make sense to move them around.

I don't know how things have changed since I gave up the gcc reins
but it used to be that the installation created a /usr/i686-pc-mingw32/
hierarchy.  I always thought that any future cross-compiler would just
actually populate that.

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

Two versions?  Whuh, Huh?  When is that ever a good idea?

What I would like to see is all of the Windows stuff isolated as much as
possible from the Cygwin.  Possibly all of the windows-only stuff could
either install in a windows hierarchy or a mingw hierarchy and symlinks
into /usr/include and (sparingly) /usr/lib could be made.

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

I believe that gegular cygwin gcc only cares about w32api for finding:
libuser32.a libkernel32.a libadvapi32.a libshell32.a .  It adds the
w32api include when -mwindows is specified and, like I said, I guess we
can't delete that now.  But we can make it clearer where these things
come from by installing them in a mingw-specific location and symlinking
them from there.

cgf


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