From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26519 invoked by alias); 28 Jan 2009 19:24:38 -0000 Received: (qmail 26400 invoked by uid 22791); 28 Jan 2009 19:24:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp124.sbc.mail.re3.yahoo.com (HELO smtp124.sbc.mail.re3.yahoo.com) (66.196.96.97) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 28 Jan 2009 19:24:31 +0000 Received: (qmail 49892 invoked from network); 28 Jan 2009 19:24:29 -0000 Received: from unknown (HELO ?192.168.1.100?) (gchicares@76.248.154.124 with plain) by smtp124.sbc.mail.re3.yahoo.com with SMTP; 28 Jan 2009 19:24:28 -0000 Message-ID: <4980B0EC.3020705@sbcglobal.net> Date: Wed, 28 Jan 2009 23:08:00 -0000 From: Greg Chicares User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: RFD: cygwin + *native* MinGW compiler References: <497FC147.306@cwilson.fastmail.fm> <497FE127.1010705@sbcglobal.net> <497FED17.4040901@cwilson.fastmail.fm> In-Reply-To: <497FED17.4040901@cwilson.fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2009-01/txt/msg00845.txt.bz2 On 2009-01-28 05:28Z, Charles Wilson wrote: > Greg Chicares wrote: >> On 2009-01-28 02:21Z, Charles Wilson wrote: >>> Pursuant to a discussion on the libtool list, I'm trying to get a feel >>> for how many cygwin users rely on the cygwin environment to drive the >>> *native* MinGW gcc compiler. >> >> I use the native MinGW compiler in a Cygwin environment, >> successfully, many hours every day. > > A few additional questions, then: > > Do you use gnu-style configured projects (autoconf, automake, libtool, > all that?) -- or some other build framework? Yes. I use autotools to build "native" versions of libraries I need, in particular libxml2, libxslt, and wxwidgets. As an example, for libxml2, here's the crucial part: [snippet begins] # For 'host' and 'build' configure options, see: # http://cygwin.com/ml/cygwin/2002-01/msg00837.html # '--disable-dependency-tracking' is required with the MinGW toolchain # in a Cygwin shell, to prevent a catastrophic dependency-tracking # failure. Apparently the problem is colons in header paths, e.g.: # c:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/include/stddef.h: # which elicit fatal errors such as this: # .deps/DOCBparser.Plo:1: *** multiple target patterns. Stop. common_options := \ --build=i686-pc-mingw32 \ --host=i686-pc-mingw32 \ --disable-dependency-tracking \ [...] CC='$(mingw_bin_dir)/gcc' \ LD='$(mingw_bin_dir)/ld' \ LDFLAGS='-lws2_32' \ [snippet ends] [It may seem weird that I use a *makefile* to invoke autotools; maybe that's just a personal quirk because I'm comfortable with make's intricacies, whereas someone else might write a shell script for that.] As for --build and --host, the rationale for --build=i686-pc-mingw32 \ --host=i686-pc-mingw32 \ is just that I copied them from the old message cited above http://cygwin.com/ml/cygwin/2002-01/msg00837.html and they do seem to work; I don't have enough understanding of autotools to explain them any better than that. I can live with '--disable-dependency-tracking' because I rarely modify the sources; if I ever do, I can 'make clean' and rebuild them from scratch. An incidental oddity is that the technique above produces cygxml2-2.dll cygxslt-1.dll cygwxmsw28_gcc_344-0.dll with 'cyg-' instead of 'lib-'. AFAICT, this doesn't matter because the MinGW linker looks for both prefixes. I happen to have Cygwin's version of some dlls as well as my own, e.g.: $where cygxml2-2.dll /opt/lmi/local/bin/cygxml2-2.dll /usr/bin/cygxml2-2.dll /bin/cygxml2-2.dll but I specify my own '-L' path to the linker. Well, actually, I guess that doesn't matter: the MinGW linker wouldn't look here: C:\cygwin\bin\cygxml2-2.dll by default anyway. For my own code that uses libraries built as above, I personally use handwritten makefiles. But my project is autotoolized, and I have coworkers who use auto* files to build it, instead of my handwritten makefiles. > Do you use cygwin's make (which version?), mingw32-make, or perhaps a > cygwin build of msys's csmake/cpmake? I use only Cygwin's make-3.81: $which make /usr/bin/make $make --version GNU Make 3.81 [...] This program built for i686-pc-cygwin > Do you use gcc's -M* options for generating dependencies -- with > mingw-gcc, these rules will be in dos format and cygwin-make-3.81 > doesn't grok them? Yes. With '-MD', I'd have the problem you mention, but I'd fix that with 'sed'. (It might be smarter to use 'cygpath', but I've been using 'sed' for this since before the '-M*' options became stable.) With '-MMD', however, I can skip the 'sed' step and everything just works. For instance, I get fenv_lmi.o fenv_lmi.o: /lmi/src/lmi/fenv_lmi.cpp \ /lmi/src/lmi/fenv_lmi.hpp /lmi/src/lmi/config.hpp ... Perhaps that's just a happy consequence of using mount -f -s -b "C:/lmi" "/lmi" mount -f -s -b "C:/opt/lmi" "/opt/lmi" (which IIRC is the sort of "identity mount" Danny uses to build gcc) and keeping all my stuff in those two directories. > What about creating static libraries? If you use mingw's ar.exe, do you > use explicit `cygpath` rules to convert unix paths to the DOS paths that > version of ar can understand, or some other technique? I don't build third-party libraries as static. When I build my own static libraries, I use MinGW's 'ar', but the command line is just /MinGW_/bin/ar -rus liblmi.a convenience.o exception.o [...] where all the '.o' files are in the directory where I invoke 'ar'. I don't use 'cygpath' at all, anywhere. Using the "identity mount" technique, and always specifying paths with forward slashes (which virtually all msw programs accept), covers almost everything I need. For 'CPP -MD', I'd use 'sed' as mentioned above. I occasionally use a couple of compilers other than gcc, and where they don't grok forward slashes, I use a C++ program as a wrapper that does the translation. > For a hint about why I started this thread, and why I am asking these > questions, see > http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html > -- especially my failures with > > $ export PATH="/c/MinGW/bin:$PATH" > $ ../libtool/configure --build=i686-pc-cygwin --host=mingw32 In particular, in that message you say: | Finally -- there's one problem without an obvious fix: cygwin's | make no longer supports dos-style paths (in target rules, which isn't the problem | here), nor in .deps files (which IS the problem). The .deps files are generated | by (mingw native) gcc, and therefore contain DOS-style paths. which is the problem I skip over via '--disable-dependency-tracking' when building libxml2 (above). MinGW gcc with '-MD' gives, e.g.: foo.o: \ C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/stdio.h \ and maybe this problem would be solved if it could drop the "C:" part, but that's no good because it would break compiles run on a "D:" drive. > This led to a suggestion that "--build=cygwin --host=mingw32" should > always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler, > NOT the native MinGW-project supported gcc (and if it IS the native > MinGW one, expect breakage). I'm not sure such a sweeping statement is > accurate, or wise -- will that assumption break people's exising > (working) setups? I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'. Here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00193.html you say that's lying to 'configure', but you also observe that I'm in excellent company. I'd be dismayed if that broke. As for the build!=host case '--build=cygwin --host=mingw32', I could try rebuilding my stuff that way if you think an extra datapoint would help. I probably tried that at some time in the past, but can't remember whether it worked. As for this sweeping statement: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00191.html | I don't think we should try to support the scenario where the MinGW gcc, | exactly as supplied by the MinGW project, is executed from within Cygwin. which I believe you're trying to counter: as evidence that at least some people in the real world care about this, you could cite the first paragraph here: http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html which echoes some of the things you said on libtool-patches, and the applicable part of this message: http://lists.nongnu.org/archive/html/lmi/2007-11/msg00007.html | Here's my rationale for some of the technical decisions. First of | all, at least for now, I've chosen to use a MinGW toolchain in a | Cygwin environment. [...] -- 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/