Re: libtool.git & cl.exe & Mingw32

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Fri, Dec 19, 2008 at 11:41:34AM CET:
> Yet I have a slight problem: for some reason the top-level wrapper (lt- 
> cli.exe in my case) tries to launch .libs/lt-cli.exe, which does not  
> exist.  What does exist is .libs/cli.exe (and actually it makes more  
> sense to me).  So I had to change libtool:

Thanks for the report.  You can make your bug reports even more perfect
by providing './libtool --tag=CC --config', and writing to bug-libtool.
And, in this case, also providing --mode=link command line and output.
;-)

> so that _spawnv be given newargz[0] (== .libs/cl.exe) as first argument 
> instead of lt_argv_zero (== .libs/lt-cl.exe).
>
> I don't understand exactly what the code is expected to do: is the  
> problem the value of lt_argv_zero (which is what I suspect), or rather  
> the fact that there is no .libs/lt-cli.exe (which I doubt).  This is  
> what I get without this change:

Both .libs/foo$EXEEXT and .libs/lt-foo$EXEEXT are needed on some systems
but I haven't checked whether that is still the case for w32 after the
recent-ish changes.

> Also, I have enabled the DEBUGWRAPPER traces by changing libtool by  
> hand, is there a better way?  Read the code I see that the wrappers  
> support options, but I found no documentation about them, and there is  
> no --lt-help: is this for Libtool developers only?

Well, adding options to the wrapper is problematic: it should be
transparent to the user program it wraps.  Thus options are bad bad bad.

You can './configure CFLAGS=-DDEBUGWRAPPER' I guess; but good thing we
didn't document that because it's bad bad bad again that we didn't stick
to LT_ namespace here.  Will fix.

Cheers,
Ralf