Absolute paths generated by libtool.
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. 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). 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. 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: 'C:/cygwin/bin/perl' -w C:/cygwin/home/build/bin/my_shell.pl ../libtool --tag=CXX --mode=link g++ -O2 -O2 -frtti -fexceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -Wall -W -Wold-style-cast -Woverloaded-virtual -pipe -g -O2 -lqscintilla2 -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem,windows -o urbidev.exe [MANY.o] -L"c:\Qt\4.2.1\lib" -lmingw32 -lqtmain -lQtXml4 -lQtGui4 -lQtCore4 ../behavior-graphs/src/libfsm.la ../behavior-graphs/src/xml_parser/libfsm_xml_parser.la C:/cygwin/home/build/bin/my_shell.pl: Rewrote the command to: sh ../libtool --tag=CXX --mode=link g++ -O2 -O2 -frtti -fexceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -Wall -W -Wold-style-cast -Woverloaded-virtual -pipe -g -O2 -lqscintilla2 -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem,windows -o urbidev.exe [MANY.o] -L"c:/Qt/4.2.1/lib" -lmingw32 -lqtmain -lQtXml4 -lQtGui4 -lQtCore4 ../behavior-graphs/src/libfsm.la ../behavior-graphs/src/xml_parser/libfsm_xml_parser.la mkdir .libs g++ -O2 -O2 -frtti -fexceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -Wall -W -Wold-style-cast -Woverloaded-virtual -pipe -g -O2 -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem -Wl,windows -o urbidev.exe [MANY.o] -lqscintilla2 -Lc:/Qt/4.2.1/lib -lmingw32 ../behavior-graphs/src/.libs/libfsm.a /home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a ../behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a -lqtmain -lQtXml4 -l
Re: Absolute paths generated by libtool.
Hello Benoit, * Benoit Sigoure wrote on Tue, Nov 14, 2006 at 05:35:03PM CET: > > My final questions are: is this necessary on Windows? Can't you keep the > relative path? Not easily. > What do you think about my weird setup mixing Cygwin/mingw/perl hooks? Mixing Cygwin and MinGW is not such a good idea IME; it gets you into numerous issues, some of which are quite subtle. I think building under plain MinGW works better if you want to avoid dependence on Cygwin's libraries. If you switch, be sure to further not rely on installed libtool libraries (.la files) with paths in the other system's format. > Are you aware of The Right Way of doing it when it > comes to automated builds on Windows? Install MinGW, install Charles' recent MinGW ports of the file command and some others (posted on this list a couple of weeks ago), use that. Try to consistenly use w32-style paths on MinGW with forward slashes, and unix-like ones on Cygwin. The more experienced w32 users on this list will be able to provide better help. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Quoting Ralf Wildenhues <[EMAIL PROTECTED]>: Hello Benoit, Hi, thanks for your quick reply. * Benoit Sigoure wrote on Tue, Nov 14, 2006 at 05:35:03PM CET: My final questions are: is this necessary on Windows? Can't you keep the relative path? Not easily. That's weird though because if you look closely at the line printed by libtool, it reads: ../behavior-graphs/src/.libs/libfsm.a /home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a ../behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a Note that the libfsm_xml_parser is printed twice, once with an absolute path (which I don't want) once with a relative path (which I do want). Now I really have no idea about libtool's logic and internals but here is an educated guess: libtool is invoked with the relative paths to the two .la. It reads them in order to know what are the dependencies. The libfsm.la depends on the libfsm_xml_parser and has the following in its .la: dependency_libs=' /home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/libfsm_xml_parser.la -Lc:/Qt/4.2.1/lib -lqtmain -lQtXml4 -lQtGui4 -lQtCore4' Here is the [EMAIL PROTECTED] full path. Now libtool recursively reads the libfsm_xml_parser.la and adds the absolute path to the .a. Next, libtool treats the other .la it was given on the command line -- which turns out to be the same as before (for libfsm_xml_parser) which leads it to add a relative path to libfsm_xml_parser.a (because the .la was provided with a relative path). Alright so I see two possible ways out: Before finalizing the command, libtool looks at all the libs and finds out that libfsm_xml_parser.a appears twice (once with an absolute path and once with a relative path) and preferes to drop the one with the absolute path. This is non-trivial to implement (knowing that two different paths point in fact to the same file) and requires more efforts. Another solution would be: why not encode the relative path to libfsm_xml_parser.la in libfsm.la ? After all, where does this path come from? The Makefile.am says that libfsm.la LIBADD is xml_parser/libfsm_xml_parser.la. Why not keep a relative path? Given the path to libfsm.la, we can find that of libfsm_xml_parser.la using a simple concatenation. This is reasonably easy to implement, isn't it? It requires very little changes and is not likely to break anything right? (I'm not a libtool expert so I'm just guessing this, I know that libtool internals are rather obfusc^H^H^H^H^H^Hcomplicated). What do you think about this? -- SIGOURE Benoit aka Tsuna _ /EPITA\ Promo 2008, LRDE ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> 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
#include
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 *
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Quoting Christopher Hulbert <[EMAIL PROTECTED]>:
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> 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
#include
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
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
Quoting Christopher Hulbert <[EMAIL PROTECTED]>:
>
>>
>> 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.
I *think* it will work. Perhaps this would convince you more:
-bash-3.2$ rm test.exe
-bash-3.2$ cat test.c
#include
#include
int
main(void)
{
printf("test.exe\n");
return EXIT_SUCCESS;
}
-bash-3.2$ cat Makefile
c:\cygwin\home\chulbert\test.exe: c:\cygwin\home\chulbert\test.c
gcc -mno-cygwin -o $@ $<
-bash-3.2$ make
gcc -mno-cygwin -o c:\cygwin\home\chulbert\test.exe
c:\cygwin\home\chulbert\test.c
-bash-3.2$ ./test.exe
test.exe
>
>>
>> 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.
Can you post the .la file?
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote: Quoting Christopher Hulbert <[EMAIL PROTECTED]>: >> 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. Nevermind. I realize now that it's executing /bin/sh which is what causes the problem. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
-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 [EMAIL PROTECTED] -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- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Quoting Eric Blake <[EMAIL PROTECTED]>: 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 __
Re: Absolute paths generated by libtool.
* Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:27:13AM CET: > Quoting Eric Blake <[EMAIL PROTECTED]>: > >According to Benoit Sigoure on 11/14/2006 9:35 AM: > > > >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. So file a bug report with Qmake, and/or work around it in your M4 macros. > If simply passing -mno-cygwin to gcc is exactly like using mingw gcc, No, e.g., for path handling reasons already stated, this is already wrong. Also note that techincally you're cross-compiling, so you need --host, and will encounter some more fun. > 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++? Forget about spaces in paths. Grab CVS Libtool, search for the last version of Peter Ekberg's Libtool patches for MSVC on this (or the libtool-patches) list. Alternatively, there's wgcc with its set of Libtool patches, also to be found in this list's archive. Neither patch is currently part of Libtool as both cause regressions for unrelated systems. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Quoting Ralf Wildenhues <[EMAIL PROTECTED]>: * Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:27:13AM CET: Quoting Eric Blake <[EMAIL PROTECTED]>: >According to Benoit Sigoure on 11/14/2006 9:35 AM: > >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. So file a bug report with Qmake, and/or work around it in your M4 macros. No because Qmake is right to use such a path in a mingw environment. Working around it in my M4 macros would solve this specific problem but it wouldnt be generic. This buildfarm is going to compile lots of different projects and I don't want to tweak each of them separately, that's why I'm trying to find generic workarounds (such as my perl scripts which rewrites properly shell commands). If simply passing -mno-cygwin to gcc is exactly like using mingw gcc, No, e.g., for path handling reasons already stated, this is already wrong. Don't be picky :P Also note that techincally you're cross-compiling, so you need --host, and will encounter some more fun. Yeah well, it's not like if I was to compile Windows binaries on Linux, I can still run what I compile etc (important for make check). 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++? Forget about spaces in paths. Grab CVS Libtool, search for the last version of Peter Ekberg's Libtool patches for MSVC on this (or the libtool-patches) list. Alternatively, there's wgcc with its set of Libtool patches, also to be found in this list's archive. Neither patch is currently part of Libtool as both cause regressions for unrelated systems. Hmm I think this means "no, libtool doesn't work with vc++" :) However, I'll look at the different patches you mentionned and will try them. Thanks for the references. Does any of you people know about cccl [http://cccl.sourceforge.net/]? It seems like an alternative to do what I want. I haven't tried it out though. Hope that helps. Yes, thank you. -- SIGOURE Benoit aka Tsuna _ /EPITA\ Promo 2008, LRDE ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Absolute paths generated by libtool.
Hey! You may want to look at www.sf.net/projects/interix-wgcc. If using interix is an alternative for you, i think wgcc is a cool tool (which, of course, i wrote ;o)). Using interix is good in any case, because it is more stable and faster than cygwin. Additionally cygwin does not correctly work on SMP machines with win2k or higher. It has the great benefit that it creates native windows executables with cl.exe (not a gcc build) and therefore produces binaries that are debuggable with visual studio. The new version thats about to be released even supports full gcc3-style dependency tracking! There is a libtool patch available that makes libtool work together with wgcc (libtool-1.5.22) and wgcc passes nearly all tests (3 fail or so) @Ralf: the patch has been tested on: i586-pc-interix3/5, hppa2.0w-hp-hpux11.11, i386-pc-solaris2.10, i686-pc-linux-gnu, powerpc-ibm-aix5.2.0.0, ia64-hp-hpux11.23, sparc-sun-solaris2.9. On interix with wgcc and gcc, on all others with gcc and some with native compilers too. I think ist mature enough to be integrated somehow, would this be ok? If you have questions, you're welcome to ask! Cheers, Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benoit Sigoure Sent: Tuesday, November 14, 2006 5:35 PM To: libtool@gnu.org Cc: [EMAIL PROTECTED] Subject: Absolute paths generated by libtool. 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. 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). 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. 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: 'C:/cygwin/bin/perl' -w C:/cygwin/home/build/bin/my_shell.pl ../libtool --tag=CXX --mode=link g++ -O2 -O2 -frtti -fexceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -Wall -W -Wold-style-cast -Woverloaded-virtual -pipe -g -O2 -lqscintilla2 -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem,windows -o urbidev.exe [MANY.o] -L"c:\Qt\4.2.1\lib" -lmingw32 -lqtmain -lQtXml4 -lQtGui4 -lQtCore4 ../behavio
Re: Absolute paths generated by libtool.
Duft Markus wrote: > Additionally cygwin does not > correctly work on SMP machines with win2k or higher. Need a shovel for that FUD you're slinging? ___ http://lists.gnu.org/mailman/listinfo/libtool
How to call AC_LIBLTDL_CONVENIENCE
There's no clear specification about the macro AC_LIBLTDL_CONVENIENCE in libtool's manual. How to call it? What does it do? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
* Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:55:38AM CET: > Quoting Ralf Wildenhues <[EMAIL PROTECTED]>: > >* Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:27:13AM CET: > > > >>If simply passing -mno-cygwin to gcc is exactly like using mingw gcc, > > > >No, e.g., for path handling reasons already stated, this is already > >wrong. > > Don't be picky :P Well, it will hit you time and again if you don't listen. Usually shortly before a deadline. > >Also note that techincally you're cross-compiling, so you need > >--host, and will encounter some more fun. > > Yeah well, it's not like if I was to compile Windows binaries on Linux, I > can still run what I compile etc (important for make check). Passing --host is necessary in general. > Hmm I think this means "no, libtool doesn't work with vc++" :) No, it meant: do what I wrote and then libtool will work reasonably well with MSVC. > Does any of you people know about cccl [http://cccl.sourceforge.net/]? Yes. It's helpful already for some things Autoconf assumes. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
