Eric Blake <ebb9 <at> byu.net> writes: > > | + /* otherwise ... */ > | + newargz[++newargc] = xstrdup (argv[i]); > > Shouldn't you handle "--" as the end of wrapper options, in case the user > really wants to pass --lt-env-* as the first option to the wrapped executable?
This caused a regression caught by the m4 testsuite. Beforehand, running the uninstalled libtool wrapper as: m4 -- -d was equivalent to m4 ./-d But now, the wrapper eats the first --, resulting in the (much different) m4 -d Running the cwrapper with an extra -- restores the old behavior; m4 -- -- -d but this is also unacceptable, because in a static build, there is no cwrapper, which means the uninstalled m4 executable would behave as if called by m4 ./-- ./-d which is also wrong. I see two options: 1. Entirely revert the portion of the cwrapper that looks for --. Instead, make the cwrapper only recognize leading --lt-* options, and pass all remaining options as is; and document that the --lt-* option namespace is reserved for the wrapper. Pro: easier to implement, simplifies the cwrapper. Con: the wrapped executable can't be handed a leading argument in the --lt-* namespace. 2. Instead of using --, invent a new cwrapper option --lt-end-options that does the same concept. Pro: no infringment on the application; if an application truly needs to use --lt-* as its first argument, it can decide whether to add the --lt-end-options marker based on whether it was compiled statically or not. Con: rather complicated just to support a corner case of uninstalled applications, and we must document how the package can tell whether the uninstalled program is a cwrapper or a static executable, to know whether --lt- end-options is needed. If you haven't guessed, I'm leaning towards option 1. Any other comments on this issue? -- Eric Blake
