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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
