Re: [PATCH] Cwrapper should not eat -- arguments

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Sun, May 25, 2008 at 06:13:04AM CEST:
> * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src)
> [file scope]: Defined all option strings in terms of macro
> LTWRAPPER_OPTION_PREFIX. Similarly defined all option string
> lengths in terms of macro LTWRAPPER_OPTION_PREFIX_LENGTH.
> [main]: Modified option parsing algorithm to pass -- on to
> target, and to not stop processing arguments when -- is seen.
> Added check for unrecognized options in reserved namespace
> defined by LTWRAPPER_OPTION_PREFIX.

This patch looks like an improvement to me.  What I don't quite
understand is that ...

> As discussed here:
> http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00067.html

... this message specifies that the first argument not matching --lt-
should end parsing, whereas your patch parses all arguments.  Also, it
does argument parsing twice, needlessly.

Now, I'm not caught up on my mail backlog yet, so I may just have missed
the message where you guys have agreed on the other way; so please only
bother explaining why if that hasn't happened yet.  (Otherwise I suppose
I will eventually get to it.)

Other than that, the only thing this patch is missing is a testsuite
test ensuring that "--" really is passed through.  (Such an addition
is preapproved.)

> Passes all but three tests on cygwin: the new-testsuite 25/72 that 
> we are used to, and one new failure: demo-exec after demo-shared.

FWIW, with linux -> mingw cross, I get failures of demo-hardcode
(trivial bug), depdemo-relink (nontrivial), and the two new DESTDIR
tests (currently 38, 39).  None of these look like new failures, in
fact the number of new test failures has considerably decreased since
I last looked which is really nice.  :-)

> It is interesting that this failure, long present on mingw, has now 
> shown up on cygwin. I traced it, and it is due to trying to populate
> the lt__PROGRAM__LTX_preloaded_symbols[] array using an 
> 'nm | $global_symbols_pipe' on a DLL, instead of a static library or
> import library.

Yes, that needs to be looked at separately.

Thanks for all your work on this!

Cheers,
Ralf