Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes

[Kean Johnston]

> Erm, are you using --host when configuring?  If so, why (are you cross
> compiling)?  If not, $ac_tool_prefix should be empty.  In any case,
It is my habbit to configure everything with:
  --host=blah --build=blah --target=blah

> while a search for a nm without the prefix is ok (since that's what
> AC_CHECK_TOOL does as well), I'm a bit uneasy about the search order: it
> should check for prefixed nm everywhere first, and unprefixed
> afterwards.
I guess the whole thing could be wrapped in something like:

  nm_to_check="${ac_tool_prefix}nm"
  [ -n "$ac_tool_prefix"] && nm_to_check="$nm_to_check nm"
  for nmfile in $nm_to_check; do
    ... the current stuff we have
  done

> I assume this change is ok.  (Searching the net for the string
> /usr/ccs/bin/elf hasn't turned up much :)
Yeah I'm pretty sure its a SCO-ism. Very people are brave
(read: stupid) enough to attempt a truely multi-ABI world.

> > Third, dont do the 'sed 1q' stuff, but grep the output returned. The
> > 'sed 1q' was causing false negatives if there was only a single line of
> > output. By using grep on the entire output, we will still get the correct
> > result, even on HP-UX if it first ejects a warning message about unknown
> > options.
>
>
> I'm pretty sure your change breaks the intended workaround for HPUX.
> OTOH, I have absolutely no idea about its relevance today; it dates from
> 1997/11/28, and I don't have any more information about this available
> (and no access to HP-UX).
Does it break it? The way I read the original code, it was doing
the nm, stripping out the first line in case it contained an
"unknown option -B" error message, and then looking to see if
the string /dev/null appeared in the output. The change I made
still achives the same result (unless I totoally mis-implemented
it).

> In any case, I believe you got the logic wrong there: /dev/null being
> present in the output is taken as a _positive_ sign, ie. that nm
Right. Thats what my code tests. If /dev/null appears in the
output, grep return 0, so I set lt_cv_path_NM and break. If
the nm -B fails, check for nm -p, and apply the same logic.
So I think you misunderstood the logic :)

>   nm -B /dev/null
> on SCO output, by the way?  Maybe we can adjust the old scheme to that?
A usage message becuase it doesn't support -B, but it does
support -p.

> Furthermore, I really don't like that you changed a shell pattern match
> to a slow grep; also, please note that grep regexes are different from
> shell patterns in that they aren't anchored, so you don't need all those
> `.*'.
Ok :) That last part is simply finger habbit. Sorry. As for replacing
a case with a "slow" grep, with all due respect I just can't buy
that argument :) grep is *so* heavily used in libtool as it is,
that if it isn't in your cache, you have much bigger problems on
your hands. Almost nowhere else in the libtool code is that case
construct used (only 4 other places in the entire libtool.m4,
one of them recently added by me, and that only becuase I copied
one of the other three usages). It is best to code to the principle
of least surprise rather than blinding efficiency. I won't argue
that using case the way you suggest is quicker, becuase it is,
but it is relatively uncommon in shell scripting in general, and
specifically in libtool itself. There is something to be said
for consistency ...

> I'm wondering whether it's easiest to just create an object file first.
> Will be most expensive, but most reliable, too..
I wondered the same thing myself when I changed that bit of code.
I am actually surprised that it works as reliably as it does. But
it does in fact seem to work well, so, if it ain't broke ... :)

Kean