Re: 2.2.6: -ofoo.exe creates foo

[Akim Demaille]

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.

lt-dummies.m4
Description: Binary data