Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Jun 21, 2009 at 08:25:00PM CEST:
>> (the shwrapper in .libs/ is intended to be ephemeral, and as an
>> implementation detail may be deleted after the link is completed.)
>
> Why is it intended to be ephemeral? What do we gain from removing it
> besides more implementational complexity through --lt-dump-script?
> (This is an honest question. I'm probably just away from the code too
> long to know the answer right away. Thanks.)
I guess it *could* stick around. But then you might get into timestamp
issues where the $var replacements in the shwrapper don't match the ones
in the cwrapper...However, for *libtool's* purposes, there's no reason
that the "else" clause below couldn't be used in all cases.
# note: this script will not be executed, so do not chmod.
if test "x$build" = "x$host" ; then
$cwrapper --lt-dump-script > $func_ltwrapper_scriptname_result
else
func_emit_wrapper no > $func_ltwrapper_scriptname_result
fi
ephemeral or not, you'd still be recreating the .libs/shwrapper every
time, which "solves" the out-of-sync possibility/problem.
So, in that respect, we could remove --lt-dump-script (although I like
the early warning this gives you on native builds that, for whatever
reason, $cwrapper just can't execute at all, regardless of any issues
with the program executable).
However, .libs/shwrapper is still an internal implementation detail. We
could get rid of it entirely at some point, clobber it after final link,
whatever. The same is NOT true of the wrapper in the $builddir (whether
shell or c). It will be present, if the app links against uninstalled
shared libraries.
However, the cwrapper is inherently fragile in
cross-build-and-run-immediately-from-emulation setups. (Heck,
*everything* is inherently fragile in that situation). So,
--lt-dump-script provides yet another way for the poor end user to
figure out what's going wrong, if something DOES go wrong (when they
can't rely on .libs/some-private-thing).
> Thanks for explaining. The paragraph is ok, but the term "target
> executable" is not; in GNU toolchain lingo, target is only relevant
> when you create a cross compiler. Please use something like "program
> executable" or so. And I agree with you that the final sentence should
> be something like
>
> The wrapper executable then launches the program.
Ack.
> I don't like that we document that we have pathlist conversion
> functions. (I also have issues with the actual functions, but let's
> discuss that in the thread where you posted the patch.) I guess it's
> ok to state that we convert paths, but I think we should limit the
> documentation to what the user should have to know.
>
> Aside, `$host' looks a bit ugly. The GCC just writes plain `host'; I'm
> not sure whether that is sufficiently clear at this point in the Libtool
> manual, but using the dollar sign is definitely not the best thing.
> Maybe using terms like `host system' or `executable for the host system'
> is a better choice?
OK. So, there's nothing factually incorrect about that section I wrote,
but you have issues with whether certain elements should be present in
the docu at all, and other stylistic issues. I can go along with your
recommendations.
>>> but actually I'd just patch the wrapper executable to allow for
>>> debugging at run time, and kill this debug mode. Do we have a
>>> pending patch for this already?
>> No. I can easily do that; the code is already structured to make that
>> possible. But isn't this adding another platform-specific behavior? Or
>> do you want me to add --lt-debug to the shwrapper, as well?
>
> Sure, that would be consistent. Of course, it is an incompatible
> change, and requires a NEWS entry.
Ack. I'll revise
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html
pending additional review comments in its thread.
>>>> +Finally, the wrapper executable supports a number of command line
>>>> +options. All of these options are in the @code{--lt-} namespace, and
>>> s/are in the @code{--lt-} namespace/begin with @code{--lt-}/
>> Ack. However, if we remove --lt-dump-script and do not add --lt-debug,
>> then the whole section could go away, because there would be no --lt-
>> options.
>
> So then this part would only be added as part of a patch to add
> --lt-debug.
Given that I suspect the --lt-debug change itself will get merged before
the surrounding documentation changes, I'd prefer to just go with that.
That is, keep all the docu changes in the same patch which documents the
cwrapper stuff AND the --lt-debug/LT_DEBUGWRAPPER addendums. Merge the
final --lt-debug patch itself sans docu. Merge the combo docu patch as
revised soon after.
>>> The testsuite additions look ok to me if we keep the -DLT_DEBUGWRAPPER
>>> thing, you could commit them as a separate patch.
>> ...or revise to test explicitly the --lt-debug switch, if you'd prefer
>> to go that direciton.
>
> Well, what direction do you prefer? Is --lt-debug good enough for you?
I kept them both, and tested both. See
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html
--
Chuck
