Re: Absolute paths generated by libtool.

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Benoit Sigoure on 11/14/2006 9:35 AM:
> Qt distributes Windows binaries for mingw only so I ended up installing
> mingw. This entails that everything is built by the mingw-gcc toolchain rather
> than by the cygwin-gcc. Anyway, I *guess* that building mingw apps in a
> Cygwin environment isn't a problem since there is probably not much
> differences between both.

Actually, there is a HUGE difference.  They are binary incompatible.
Cygwin strives to provide a relatively full POSIX interface, but the
resulting executable depends on cygwin1.dll.  mingw provides a
minimalistic POSIX interface, as a thin wrapper around the limited
capabilities that Windows already provides, but the resulting executables
are stand-alone.  You cannot reliably link object files or libraries
created in mingw with those created in cygwin.

And as this thread pointed out, 'gcc -mno-cygwin' exists in the cygwin
environment for compiling a mingw app; it is basically an alternate way to
spell the cross-compiler i686-pc-mingw-gcc.  If you aren't familiar with
cross compilation, and the set of problems that brings, then you should
compile mingw apps in MSYS or some other mingw environment, rather than
cross-compiling them from cygwin.  Or consider making your project depend
on cygwin in the first place; since cygwin tends to be the more POSIX-like
environment, the port from Unix to cygwin is easier.

> C:\Foo\Bar: C:\Baz\Qux
> Which is a problem for cygwin's GNU make (since it sees "C" as a target). For
> some reason the mingw GNU make has no problem with this kind of rule, I guess
> they patched it.

It goes back to the philosophy of the two projects.  Cygwin wants to be
like Linux, and on Linux, c:/foo/bar is a target.  Mingw wants to be a
wrapper around Windows, and on Windows, c:/foo/bar is a file name in the c
drive.  The make mailing list has more discussion on whether a build of
make (post-3.81) on cygwin should special case drive letters or not, but
cygwin make will not support anything until it is made official in the
upstream package.


> Nevermind, let's use mingw GNU make. The problem is that
> when make runs commands such as C:\Qt\4.2.1\bin\moc.exe, the backslashes are
> interpreted by the shell (cygwin's shell) which leads to the execution of the
> command C:Qt4.2.1binmoc.exe.

Have you tried writing the makefile with forward slashes?  Windows tends
to do all right with them, in spite of the fact that they are not the
documented directory separator.

> 
> My final questions are: is this necessary on Windows? Can't you keep the
> relative path? What do you think about my weird setup mixing
> Cygwin/mingw/perl hooks? Are you aware of The Right Way of doing it when it
> comes to automated builds on Windows?

It's generally nicer if you stick with an all mingw or all cygwin
environment; and using cygwin's 'gcc -mno-cygwin' is a little more
friendly than using the cygwin environment to invoke a native mingw 'gcc'.
 That's because, as you noticed, the two environments have a completely
different notion on how path names should be handled.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFWpuO84KuGfSFAYARAtagAKCUecgFOFJmgfHA7pu1vCsVqHpTCgCfWZ8n
5MSIZdHuVMUCdt4HFqG/i6E=
=jvpQ
-----END PGP SIGNATURE-----