Re: Absolute paths generated by libtool.

[Benoit Sigoure]

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