libtool-patches
[Top][All Lists]
Advanced

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

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


From: Kean Johnston
Subject: Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Date: Tue, 01 Nov 2005 08:56:58 -0800
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

 nm_to_check="${ac_tool_prefix}nm"
 [ -n "$ac_tool_prefix"] && nm_to_check="$nm_to_check nm"

Space missing before ]:   ^
Right :) I was just typing blind to make sure you were OK with
the concept.

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
*DOH* You are, of course, correct. My grep test fails.

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) .
..
        [-C]  print decoded C++ names
        [-V]  print version information on stderr
        [-h]  suppress printing of headings
        [-n]  sort external symbols by name
        [-o]  print value and size in octal
        [-p[l]]  produce terse, easily parsable output
                [l] modifier for -p option - produce long listing
                        of output
        [-r]  prepend the name of the object file or archive to each
                output line
        [-u]  print only undefined symbols
        [-v]  sort external symbols by value
        [-x]  print value and size of a symbol in hex
keats:~% echo $?
1


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.
Believe me I know :)

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

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?

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.

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.

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.

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

Kean

Cheers,
Ralf






reply via email to

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