[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Absolute paths generated by libtool.

From: Benoit Sigoure
Subject: Re: Absolute paths generated by libtool.
Date: Wed, 15 Nov 2006 07:27:13 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Eric Blake <address@hidden>:

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.

I know that, but I was talking in term of environment: configure and libtool
look at their environment (uname etc) to detect the different triplets and
infer some rules about what has to be done depending on that, and my guess was
that i686-pc-cygwin is extremly close to i386-pc-mingw. Of course I know that
cygwin and mingw have incompatible toolchains and thats why I ended up putting
mingw's toolchain in my PATH first.

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.

Yes that's what I thought to, but Qt 4 doesn't work on cygwin ATM and they
distribute Windows binaries only for mingw.

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.

Yeah that's what I guessed.

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.

Yes, I know this works. Unfortunately, some bits of the Makefiles come from
Qmake which is definitively targetting a mingw env.
Let's make it clearer: I don't want to use Qmake for my buildsystem so I wrote a collection of M4 macros that detect the proper flags for building Qt apps. This
is simply done by creating a dummy conftest.cpp/conftest.h, invoking Qmake to
generate a Makefile. Then I simply save the values of some variables in that
generated Makefile (DEFINES is AC_SUBST'ed as QT_DEFINES etc).
That's why I *need* this kind of thing to work.

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.

If simply passing -mno-cygwin to gcc is exactly like using mingw gcc, I'll give
it a try because this could possibly solve my last problem. Do I have to
considere it as a C/CXXFLAGS? LDFLAGS? Both?

By the way (that's slightly out of topic) my next target is to get it to work
with VC++ (sigh!). Will automake/autoconf and especially libtool support vc++?
It looks like creating libraries is *very* different with vc++.
Actually, what I plan to do is that: if autoconf/automake/libtool support vc++,
I'll keep the same setup for automated builds and simply ./configure with
--host=.. --build=.. so that configure uses vc++.
If they don't, do you have any suggestion?

SIGOURE Benoit aka Tsuna
 /EPITA\ Promo 2008, LRDE

reply via email to

[Prev in Thread] Current Thread [Next in Thread]