libtool
[Top][All Lists]
Advanced

[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: Tue, 14 Nov 2006 21:24:16 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Christopher Hulbert <address@hidden>:

On 11/14/06, Benoit Sigoure <address@hidden> wrote:
Hello folks.

[SNIP]

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.

Good to know, thanks!



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


Sounds cool too, anyway I use mingw gcc.



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?

I don't think so, this problem is independant of make.
make will always end up running /bin/sh -c C:\Qt\4.2.1\bin\... which will always yield C:Qt4.2.1bin. Unless your patch (which I haven't looked yet) also provides
some black magic to reverse the backslashes.



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).


I highly doubt it's the case (although I haven't tried ATM) because the .la has
references to the build dir.

--
SIGOURE Benoit aka Tsuna
  _____
 /EPITA\ Promo 2008, LRDE





reply via email to

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