This is the mail archive of the cygwin-developers@cygwin.com 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]

Re: MinGW compilation on Windows


Andrew Begel wrote:

>>
>> > That's not the problem. MinGW doesn't pretend to do more than it
>> > advertises; simply a gcc that accepts both windows and 
>>unix style paths,
>>
>>unix-style -> C:\foo\bar = c:/foo/bar ?  That's *not* unix 
>>style.  It's 
>>still a multiple-root colon-delimited pathspec.  AFAIK 
>>mingw's gcc has no 
>>knowledge of any cygwin-style mount system (a system which 
>>gives cygwin a 
>>true unix-style single-root pathspec (and no colons)).
>>
>>
> 
> Actually, MinGW assumes c: if you leave off the drive letter on a path.
> That, combined with its ability to use forward slash or backward slash
> as a directory delimiter, means that if you use Cygwin to mount c:\\foo
> as /foo, Mingw and Cygwin will both accept the same pathname for that
> directory. That's kinda nice.


Actually, apps that assume all paths begin with C: have always kinda 
annoyed me.  My C: is a FAT partition (tiny) for multibooting.  WINNT lives 
on E:.  Win95 lives on D:  My laptop is the same way (sorta): I normally 
use W2K (D:) while W98 is on C: for rare compatibility emergency use.  (And 
both have Linux in various non-windows-visible partitions)

 
>>Not yet.  Earnie (maintainer for cygwin's mingw-runtime and w32api 
>>packages) has promised to provide the required g++ libs, but 
>>hasn't yet.
>>
>>
> 
> This'll be nice.
>  
> 
>>What if mingw (or a mingw-aware cgywin person) provided a TRUE 
>>cygwin-hosted, mingw-targetted cross compiler?  Such a compiler would 
>>natrually look in /usr/include/mingw and /usr/lib/mingw (or even 
>>/usr/i686-pc-mingw/include &tc), so that part is okay.
>>
>>Then the problem boils down to insuring that the cygwin 
>>mingw-runtime, 
>>w32api, and "mingw-cross"(?) packages are kept up-to-date -- 
>>either by 
>>mingw people or by mingw-aware cygwin people.  Ideally, these 
>>packages 
>>would come from the same source tree as the "native" mingw tools 
>>(currently, Earnie keeps our w32api and mingw-runtime in sync 
>>pretty well, 
>>I think).
>>
>>That's (keeping packages current) a much easier problem to 
>>solve than some 
>>of the other ideas I've seen floating around...
>>
> 
> This would suit me just fine. :)


Cool.  Me too.  Stay tuned, things may begin happening...

--Chuck



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