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