Re: Absolute paths generated by libtool.

[Christopher Hulbert]

On 11/14/06, Benoit Sigoure <address@hidden> wrote:
> Hello folks.
>
> I'm developing Qt-based applications. The build system is controlled by the
> autotools rather than by Qmake.
>
> I'm porting our projects on Windows. We're using an automated build system
> (buildbot.sf.net) to build every commit on Linux/OSX/Windows. Automating the
> process on Windows proved to be really annoying. I looked at how other
> projects do it (Python, KDE, Subversion etc.) they all seem to use hand
> written .bat files and/or Makefile.vc (for Visual C++) with nmake and co. I
> didn't want to deal with special Makefiles or setting up a special build
> system for each project, so I tried to do something more generic.
>
> Things are rather complicated but I'll try to explain them here. Everything
> might not be relevant to the problem described below but I suppose you people
> have a good experience about porting applications so you might be able to
> advise me.
>
> First off, I chose to use a Cygwin environment for the buildfarm. This was
> convenient since Cygwin comes with lots of packages (python, vim, zsh etc)
> and make it easy to have a complete environment on the Windows machine. The
> buildbot (which is a python app) runs in that environment.
>
> 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.

You can compile in mingw mode by using the "-mno-cygwin" flag to cygwin gcc.

> However, doing this made me run into several problems. For instance, Qt
> generates Makefiles that have rules such as:
> 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. 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. I tried to use MSYS's shell (the shell provided
> with mingw) or cmd.exe directly but this wouldn't work (for some reason it
> always ended up running C:Qt4.2.1binmoc.exe).

I ran into this recently with the latest cygwin make 3.81. The move
from 3.80 to 3.81 dropped support for dos style paths. here is a link
to a patch which worked for me. Note that you need to install the
source for make which ends up in /usr/src.

http://thread.gmane.org/gmane.comp.gnu.make.windows/2058/focus=2147

And here's an example after compiling.

-bash-3.2$ cat Makefile
c:\cygwin\home\chulbert\test.exe: c:\cygwin\home\chulbert\test.c
       gcc -mno-cygwin test.c
-bash-3.2$ cat test.c
#include <stdlib.h>
#include <stdio.h>

int
main(void)
{
   return EXIT_SUCCESS;
}
-bash-3.2$ make
gcc -mno-cygwin test.c


> My idea was to write a perl script and to invoke make SHELL=my_shell.pl. That
> script would rewrite the command properly so that it works within the Cygwin
> environment. I succeeded and I can now run configure scripts and compile my
> projects using that shell-wrapper.
> In order to make this automatic and transparent, I have ~/bin first in my
> PATH and I wrote a shell script named make.exe there that forwards the
> invocation of make to mingw's GNU make with the SHELL variable set.

Hopefully you can get rid of all this if you use the patched make?

> However, on last problem remains, and that's where libtool comes in. MingW
> applications don't know anything about the cygwin environment, they're not
> aware of the pseudo filesystem emulated by cygwin. At the end of the
> compilation, libtool is invoked to link the final executable but for some
> reason, it transforms a relative path in an absolute one:

*snip link*
> /home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a:
> No such file or directory

Make sure to specify prefix and exec-prefix in the form
"c:/path/for/install". This is what libtool puts in the .la (I think).


* snip other question, etc *