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: Ralf Wildenhues
Subject: Re: 2.2.6: -ofoo.exe creates foo
Date: Tue, 25 Nov 2008 22:10:04 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Akim Demaille wrote on Tue, Nov 25, 2008 at 10:38:56AM CET:
> Le 24 nov. 08 à 21:30, Ralf Wildenhues a écrit :
>> * 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

So you are the first person in half a decade that claims to use pw32.
Do you *really* *actually* use pw32?  Or did you just specify that
in --host, and really you are using some MinGW/MSYS code?

There may be some places needing help for pw32.
We've let it rot a bit because it was believed dead.

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

Confirmed.

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

With both macros, I don't quite understand how an external libtool.m4
should be pulled in:
* _LT_REQUIRED_DARWIN_CHECKS is m4_require'd and m4_defun_once'd.
  We never in history AC_DEFUN'ed it.  How in the world does aclocal
  see it in an external *.m4 file?
* _LT_AC_PROG_CXXCPP isn't even used in the current git tree.
  Why does aclocal decide that it should be needed?

Which aclocal and autom4te version do you use BTW, and which version is
the installed libtool.m4 macro from (please distro version, too, so we
can check whether it's distro-specific changes that caused this bug)?

Thanks,
Ralf




reply via email to

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