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

[Ralf Wildenhues]

Hi Kean,

* Kean Johnston wrote on Tue, Nov 01, 2005 at 05:56:58PM CET:
> 
> >>>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?
> keats:~% /usr/ccs/bin/elf/nm -B /dev/null
> /usr/ccs/bin/elf/nm: ERROR: Illegal option -- B
> i386/usr/ccs/bin/elf/nm: Usage: i386/usr/ccs/bin/elf/nm [-?CVhnopruvx] 
> file(s) .
*snip*

OK.  What's the output with -p?

> >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.
> Right, I know and get that. But this was a configure-time check,
> not a runtime check and I was just being consistent. Now mind
> you, configure itself is pretty damned slow :) On my system
> it takes, for example, 11 times as long to configure automake
> as it does to make and make install.

Yes, but that is because the `make' part in the Automake package has
almost nothing to do.  But granted, point taken.

First thing you can usually do to improve `configure' execution time is
choose a faster shell; select with
  /bin/foosh path/to/configure CONFIG_SHELL=/bin/foosh
With libtool, make sure it finds a suitable shell-builtin $echo.

> So I am all for speeding up configure in any way we can too. When we
> iron out how to do the actual test I will happily convert it back to a
> case check.

Just leave it the way it is for now (with the `case'); if we can single
out SCO `nm -p' output, we're set.

> As a side note, would it be worthwhile auditing libtool.m4
> to see where there are *other* places we can eliminate grep
> with case statements?

Not too much.  Places where it gets executed several times (potentially)
are better candidates.  But better even is to measure, find bottlenecks,
and then try to fix those (setting max_cmd_len if possible is a good
example, the test takes very long).  Otherwise, I'd rather be in a
"don't change this, unless it matters" mood.

Mind you, though, those patches should be against CVS HEAD only, and
will be post-2.0.  Also, there are a few pending patches for ltmain.m4sh
and ltsugar.m4 (and libtool.m4, which I haven't finished thinking about
yet  :).

> I was thinking about this some more. Creating a small object
> and checking its output could actually be quite useful, and
> possibly even combine two tests. (AC_PROG_NM and
> AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE).  Even without combining
> them, creating an object file with the compiler we will
> actually be using is probably a good thing. Here's why.
> Consider the multi-ABI world again, where tools may behave
> differently depending on the object type (like SCO, for
> example). The current check for /dev/null isn't really
> an accurate refelction of what the tool can/cant or will/wont
> do. So for the sake of pure correctness, creating the
> object is the best way to go.

Do you need different `nm' programs for different ABIs on SCO?
(The issue with the /.../elf path suggests this.)

But yes, that may be a good idea; for cross-compile setups as well.
Still, I'm a bit wary to rewrite a test completely for branch-1-5.
We've been burnt with broken releases before, they cause needless extra
work.  So if we can 'fix' this one now without rewriting, I'll rather
take the fix now, and take time for the rewrite.

Nonetheless, you're surely free to post patches, and I'm not the only
one to approve them.  :)

> If we did that, and we carefully chose the list of symbols
> that we put into the test, we could either feed the result
> of the nm into AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE or else
> combine the two tests. That way we save on yet another
> fork/exec inside A_L_S_G_S_P for symbols we already need to
> extract in AC_PROG_NM.

Hmm.  Yes, probably.

> Oh and while I am thinking of saving forks/execs, how
> universal is 'sort -u' ? Thats quicker than 'sort | uniq'.

`sort -u' is used in Autoconf, so I guess it's portable[2].
In any case, remember the rules about optimization[1].  An
insignificant speedup is not worth the hassle of one new bug.

Cheers, and thanks also to Tim for his reply!
Ralf

[1] http://lists.gnu.org/archive/html/automake/2005-10/msg00068.html

[2] If you're interested, good portability guidelines are:
- XSI/SUS shell and commands manpages, Bourne's original tutorial
- Sven Mascheck's shell pages and Paul Jarc's lintsh page
- the CVS Autoconf documentation (Portable Shell section)
  (it's grown quite a bit since 2.59)
- autotools mailing list archives (sometimes)
- others I've missed