[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool.git & cl.exe & Mingw32
From: |
Ralf Wildenhues |
Subject: |
Re: libtool.git & cl.exe & Mingw32 |
Date: |
Sun, 21 Dec 2008 17:49:01 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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