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

[Ralf Wildenhues]

Hi Kean,

* Kean Johnston wrote on Tue, Nov 01, 2005 at 08:34:00AM CET:
> >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

Don't do that.  You don't want cross_compiling turned to `maybe' if you
in fact aren't.  (Surely, for multi-ABI, there is a point, but then not
all blah's above might be the same. :)

> >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"
Space missing before ]:   ^

Also, you should always use `test' in m4 macros, to avoid needing to
m4-quote the brackets.

>   for nmfile in $nm_to_check; do
>     ... the current stuff we have
>   done

Yes, that looks good.

> >>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).

Wrong.  The original code looked *only* at the first line.
The problem with looking at all lines was _presumably_ this:
HP-UX nm outputs
| nm: unknown option "B" ignored
| /dev/null: no symbols

or something similar.  Also checking the second line would mean, that we
falsely think this nm accepts -B, because we found the string
`/dev/null'.  Got it now?

*snip*
> So I think you misunderstood the logic :)

Try again. :)

> >  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.

Care to cut and paste it?  Thanks.  What's the return value?

> >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 ...

Sure.  configure isn't so much of a problem as ltmain.  But you may
search the libtool list archives for bug reports about its slowness.
Least surprise is ok, whereever we're unsure about what works, but
on w32, even current systems can only do a few hundred fork+exec per
second, and it starts to show when script execution takes longer than
subsequent compiler execution.  See, not everyone else's needs are your
needs, and libtool is to be generally usable.

> >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 ... :)

ACK.

Cheers,
Ralf