Re: RFD: cygwin + *native* MinGW compiler

[Greg Chicares <gchicares@sbcglobal.net>]

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/