This is the mail archive of the cygwin 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: Eliminating -mno-cygwin from gcc?


[I haven't read the whole thread yet, so I reserve the right to revise and extend. Also, to say something somebody else already did, or otherwise generally make an idiot of myself]

Christopher Faylor wrote:
How about if we eliminate -mno-cygwin from future releases and either
provide our own mingw cross-tools or wrap the offerings from mingw.org?
This would mean that instead of saying 'gcc -mno-cygwin', you'd say:
'i686-mingw-gcc' which would, I know, make a few computers spontaneously
self-destruct however, I really don't think that the -mno-cygwin belongs
in gcc.  No other port of gcc has anything like this.

I agree in principle -- and would prefer a cygwin-hosted cross-compiler, rather than using the mingw offerings, for two reasons which I will get to later.


But first, the most important question: what is Dave Korn's opinion? As the current GCC maintainer for cygwin, a change like this would fall most heavily on him [*] The number of packages Dave releases wouldn't change, but there will be inevitable ripples that he'd have to deal with.

[*] And on the maintainers of the binutils package (cgf? Corinna?), the mingw-runtime package, the w32api package, and the mingw-zlib,mingw-bzip2 packages. (The last two are mine, and are no-brainers. But the other three will also get some ripple from this proposal)

My reasons for preferring a cygwinH-mingwT cross compiler:

[1] the mingw offerings are not always in sync with cygwin version-wise. Presently they are on:
Current=3.4.2,
Prev=3.2.3, 3.3.1, 2.95.3
Candidate=3.4.5
Proposed=3.4.5+DW2
and not all have the same set of frontends. Which one would we provide (and note that 3.4.4 -- our current cygwin gcc version -- is not one of the choices)?


[2] The MinGW gcc does not understand unix paths, only dos paths. This will lead to unexpected un-cygwin-ness when using the compiler, expecially when running configure scripts, etc.

MinGW works around this with their MSYS fork of cygwin, which auto-converts stuff on the command line to/from dos format when the target program is non-MSYS-linked (but then there are those corner cases: Win32-style options (/Fo:bob), cmdline args with embedded paths (-I/usr/mingw), etc.

I don't think we want to imitate that in cygwin. But it's still better if we can pass unix-style paths to the "-mno-cygwin" compiler. This argues for a cygwin-hosted true cross compiler, rather than using the native-win32-hosted version from MinGW.

But let me re-iterate: the opinion of Dave and those other maintainers are the controlling one, IMO. (Oh, and does Dave build existing gcc releases natively, or on linux? If the latter, then the mingw compiler will be a three-way: linuxB-cygwinH-mingwT...)

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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