X-Spam-Check-By: sourceware.org Message-ID: <46C76EB2.9090002@cwilson.fastmail.fm> Date: Sat, 18 Aug 2007 18:12:02 -0400 From: Charles Wilson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cygwin Mailing List Subject: [Fwd: Re: Automatic detection of MinGW toolchain (the one that comes with Cygwin)] Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/