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