Summary
    Isn't the binutils ar(1) broken?  If the "ranlib"-equivalent
    function is not vital, how about disable the function?  If the
    "ranlib" function is not necessary, the Berkeley ar may be better.

The GNU binutils' ar(1), which is our current ar can't create correct
random archive of ELF object files.  Even if you run ranlib(1)
on the archive, the TOC of symbols is still invalid (try file(1)
or head -2 on the archives).
I confirmed (or have reports of) the problem on m68k, i386
and sparc object files in ELF.

If you use Berkeley ar and run binutils ranlib(1) on the archive,
you'll have correct random libraries.

The broken archive causes some problems.
ld(1) can't make use of the TOC (slow!), and
make(1) can't see the time of the TOC and always treats
the libraries out-of-date.

The binutils ar(1) does ranlib(1)-equivalent function and
tries to create TOC of symbols at archive creation (and the
function is broken).
The function seems to be needed by POSIX, but, ....
Is this necessary?

If ar(1) didn't do ranlib, ar(1) would be architecture- and
object format- independent and the current ar could handle
any format of any architecture at present and in the future.
Isn't it nice?

If the ranlib function is not required, we can use Berkeley ar.
The Berkeley ar is much faster, smaller, less buggy, and
under less restricted license compared to the binutils' one.
Why don't we use it?

Thoughts?

 1. The current behaviour is not a problem.
 2. Fix the binutils ar.
 3. Use ar without "ranlib" function.
 4. other
--
ITOH, Yasufumi <itohy@netbsd.org>