Mail Archives: cygwin/2007/01/31/21:18:56
[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/
- Raw text -