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]

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

FYI, from the 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.


=============== 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:'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:
Problem reports:

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