[Fwd: Re: Automatic detection of MinGW toolchain (the one that comes with Cygwin)]

[Charles Wilson]

FYI, from the eclipse.tools.cdt newsgroup.  CDT is the "C/C++ 
Development Tooling" for the Eclipse platform -- in short, a cross 
platform IDE for C/C++ programming.  On Windows, it supports both cygwin 
and mingw compilers.

--
Chuck

=============== begin forwarded message ==============
GW wrote:
> For quite some time now Cygwin setup utility has some packages
> starting with "mingw-*" and it would be great if CDT would auto
> detect this and use them.

This is a really bad idea.  There are only a few cygwin packages related
to mingw:
   (1) w32api
   (2) mingw-runtime
   (3) gcc-mingw-*
   (4) mingw-bzip2
   (5) mingw-zlib
cygwin isn't really "set up" to fully host true mingw development. It
provides only the barest minimum of win32 and mingw libraries that are
needed to self-host those of its own tools that, for one reason or
another, cannot themselves depend on the cygwin runtime. It's a short
list: the cygwin runtime itself, setup.exe, strace.exe, cygcheck.exe,
and dumper.exe.

(4), (5): The last two are provided solely because they are needed in
order to compile cygwin's own setup.exe program (which must be a
pure-native w32 app, and not a "cygwin" app, because setup.exe is used
to update/install the cygwin DLL itself and must be able to run on a
pristine system that doesn't yet have cygwin installed).  As a matter of
policy, the cygwin project will not provide any other non-cygwin support
libraries; there will be no "cygwin" packages like mingw-jpeg, or mingw-gtk.

(1): w32api is present for two reasons: the first is that it is needed
to compile the cygwin runtime itself -- cygwin1.dll maps posix calls
onto the underlying win32 system, so it obviously needs the .h
definitions and .a libraries to compile and link against.  The second
reason is described below.

(2), (3): the gcc-mingw-* packages provided by cygwin are NOT actual
compilers.  Instead, they provide only the related private header,
startup, and private-tool files that a mingw compiler WOULD use.  For an
end-user, you actually use the "cygwin" gcc/g++/g77 drivers, but you
pass a special flag: -mno-cygwin.  This tells the cygwin driver program
to use the mingw-related private header and startup files (it also
slightly modifies the -L library lookup path).

However, this is NOT the same as using a true mingw compiler: the cygwin
drivers don't understand native paths (like: C:/foo/my.c) Rather, they
only understand 'cygwin-ized' paths. Also, unless you REALLY know what
you're doing, it's very easy to accidentally pull in a cygwin-dependent
library, because /usr/lib is NOT removed from the library search path,
nor is /usr/include removed from the preprocessor path.


[ed: this paragraph was not in the original newsgroup message]
If you want to compile "native" windows programs, you are REALLY better 
off using the native windows port of gcc -- mingw -- and not the 
kinda-sorta-maybe version provided by cygwin's "gcc -mno-cygwin".


But here's the real kicker: sometime relatively soon, the -mno-cygwin
support is going to be eliminated from cygwin compilers, and the cygwin
project will instead ship a "cygwin-native" compiler suite, and a
"cygwin-host,mingw-target" cross-compiler.

As with all cross-compilers, it would have its own system root.
Therefore, a cygwin "w32api" package might have to install the same
files in two different places -- once in the "regular" place so that
cygwin's own compiler can use it, and once in the mingw-target
compiler's system root.  There are actually a lot of system-architecture
changes bound up in this, so it's going to take a while: the term "soon"
is, well, relative.  But it /will/ happen.

> This means that a user who would like to
> have the ability to compile with Cygwin GCC and MinGW GCC doesn't
> have to install 2 separate programs/compilers for this. He just needs
> to specify to gcc the "-mno-cygwin" parameter and set correct
> inclusion and library paths (I think the needed ones are
> /usr/include/mingw/ and /lib/mingw/).

Don't forget /usr/include/w32api.

However, as I mentioned above, the -mno-cygwin parameter is going to be
phased out.  Primarily because people think it does something it
doesn't, and that leads to way too many support requests on the cygwin
mailing list:
Q: My unix app compiles on cygwin.  Now I want to make a version that
doesn't use cygwin, so all I need to do is say -mno-cygwin, right?
A: Wrong...you're still making posix calls...
Q: you guys suck!
A: #!@%!

> Therefore I would like to suggest a feature for auto detecting this
> MinGW toolchain that is contained within Cygwin and setting all the
> needed paths (for bin, include, lib). Now it is possible to do all
> of this manually, but it isn't very nice and if you forget something
> some mysterious errors appear).

I'd recommend against this.  Truly, the -mno-cygwin is a historical
artifact and is now only "necessary" -- as far as the cygwin team is
concerned -- for building certain of cygwin's native tools. (And it
isn't really necessary at all; other solutions such as a true
mingw-target cross compiler are now possible).  Given the amount of pain
and annoyance the -mno-cygwin switch brings with it, coupled with the
minimal benefit *for the cygwin project and cygwin users*, it will be
removed "soon".

At best, you might want to define *a different* toolchain (not extend
the existing true MinGW toolchain, nor the existing Cygwin toolchain).
This *new* toolchain definition could descibe a 'mingw personality' of
the cygwin compiler (because it will need `cygpath` support, unlike the
true MinGW one.  Later, once -mno-cygwin goes away, you could define a
second, *different* toolchain, that describes a
cygwin-hosted,mingw-target cross-compiler. But, IMO, in no case should
either the existing mingw or cygwin toolchains be bastardized to support
-mno-cygwin.  It's just /asking/ for trouble if you do that.

=============== end forwarded message ==============

--
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/