bug-libtool
[Top][All Lists]
Advanced

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

Re: 2.2.6: -ofoo.exe creates foo


From: Akim Demaille
Subject: Re: 2.2.6: -ofoo.exe creates foo
Date: Tue, 25 Nov 2008 10:38:56 +0100


Le 24 nov. 08 à 21:30, Ralf Wildenhues a écrit :

Hi Akim,

Hi Ralf!

* Akim Demaille wrote on Mon, Nov 24, 2008 at 05:06:17PM CET:
I suppose our setup is quite unusual.  We use a GNU/Linux machine and
Wine to compile and link using VC++.  Our configure computes that
EXEEXT=.exe, which is fine.

Erm, so $host is w32?  If yes, ...

address@hidden grep -w host Makefile
host = i586-unknown-pw32

But then libtool 2.2.6, when linking an
executable with dependencies on dynamic libraries, discards the
extension.

$ ./libtool --mode=link --tag=CXX g++ -o foo.exe foo.lo sdk-remote/
src/libuobject/libuobject.la
libtool: link: g++ -o .libs/foo.exe .libs/foo.o -Wl,-bind_at_load
sdk-remote/src/libuobject/.libs/libuobject.dylib /Users/akim/src/
urbi/2.0/kernel/_build/i386-apple-darwin9.5.0/sdk-remote/src/
liburbi/.libs/liburbi.dylib /Users/akim/src/urbi/2.0/kernel/_build/
i386-apple-darwin9.5.0/sdk-remote/lib/libport/.libs/libport.dylib /
Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.5.0/sdk-
remote/jpeg-6b/.libs/libjpeg.dylib

... then why "dylib" here? Is there an MSVC cross compiler from w32 to
Darwin?  And if this is a cross-compiler, then why is it called "g++"
and not something like i586-mingw-msvc-g++?

I should have stayed on the VC++ machine, sorry. It was just easier to prove my point, and show that actually I fail to have libtool produce wrappers with .exe. For instance in my build tree of today's libtool from master (On my OSX, nothing crossed at all, purely native):

$ echo "int main() { return 0;}" > foo.cc
$ ./libtool --mode=compile --tag=CXX g++ -c -o foo.lo foo.cc
libtool: compile:  g++ -c foo.cc  -fno-common -DPIC -o .libs/foo.o
libtool: compile:  g++ -c foo.cc -o foo.o >/dev/null 2>&1
$ ./libtool --mode=link --tag=CXX g++ -o foo.exe foo.lo libltdl/ libltdl.la libtool: link: g++ -o .libs/foo.exe .libs/foo.o -Wl,-bind_at_load / Users/akim/src/libtool/_build/i386-apple-darwin9.5.0/libltdl/.libs/ dlopen.a libltdl/.libs/libltdl.dylib
$ ls foo*
foo     foo.cc  foo.lo  foo.o

It does not obey my -ofoo.exe.

(this is under osx, hence the extensions, but it's unfortunately the
same on the GNU/Linux box using VC++ as a compiler).

Well, I certainly cannot reproduce it here, and would like to see
 ./libtool --config

output for such a cross setup, as well as the configure command line
used (did you pass --host?).

Does not seem to be relevant actually, so I didn't send it to you. But if you think it matters, I can send libtool --config from my osx.



FWIW, current git has some (quite a few, actually) changes related to
such cross setups, but I don't think any of those would influence what
you are seeing.

The bootstrap of libtool is real painful. Studying the verbose output of aclocal it appears it pulls libtool.m4 because of two obsolete macros. Adding the following stub file to libltdl/m4 cures all my pains. It is probably worth the trouble to add it. Or maybe to add it to lt-obsolete.m4.

Attachment: lt-dummies.m4
Description: Binary data






reply via email to

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