libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.


From: Ralf Wildenhues
Subject: Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.
Date: Wed, 8 Sep 2010 21:29:07 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

Hello Peter,

* Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:39PM CEST:
> Subject: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.
> 
> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating
> the cammand line length if the name lister has @file support and

s/cammand/command
comma after support (otherwise the sentence is misleading).

> always use the @file branch. This works around the fact that all
> objects and archives still need to be transformed to toolchain
> format for toolchains that does not support @file. At least for

do not

> toolchains that have @file support...

s/\. At/, at/
Please no ellipses in ChangeLog entries, thanks.

I guess I'm a bit put off by this patch in that it makes it harder on
GNU/Linux to debug libtool by copying and pasting the commands that it
outputs, because the response file will be invisible.  On this system,
there's no advantage as long as the command line is not too long.

So, the question is whether to replace the patch with one that changes

-             if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; 
then
+             if { test "$len" -lt "$max_cmd_len" \
+                  || test "$max_cmd_len" -le -1; } \
+                && $tool_conversion_not_needed_on_this_system; then

WDYT?

We can (and need to) find out during the next test cycle whether the nm
@file is functional or not.

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]