Solaris, combining a bunch of convenience archives

[Ralf Wildenhues]

Apparently, both the Solaris compiler driver `cc' and the linker
fail when only given a bunch of convenience archives, but no plain
object, iff for example in 64bit mode like with
  CFLAGS=-xarch=v9

because they seem to try to infer the link mode by the type of the first
object they encounter (tested on sparc-sun-solaris2.8):

| ld: warning: file .libs/libconv.a(conv.o): wrong ELF class: ELFCLASS64

A fix would be to force the linker into 64bit mode (with `-64'), when
libtool does the link with `$LD'.  We can do that in libtool.m4's
_LT_ENABLE_LOCK together with the other such settings (what an
inappropriate macro place and name, though, by the way), patch to follow
when tested.

Since on Solaris we sometimes use `$CC' for linking though (CVS HEAD
uses $CC instead of $LD in this case), this is not sufficient.  AFAICS
the linker driver fails when all he gets is `-Wl,..' args:

$ cc -G -h libfoo.so.0 -o .libs/libfoo.so -Wl,-z -Wl,allextract,.libs/libconv.a 
-Wl,-z -Wl,defaultextract -ldl -laio -lm -lnsl -lsocket -lc -xarch=v9 -mt
usage: cc [ options] files.  Use 'cc -flags' for details 
$

One workaround for the user would be to add a dummy object to the link
line.

I haven't found a good way to persuade the compiler driver to invoke the
linker anyway yet.. does anybody have a better idea than going back to
linking with $LD (maybe only in the 64bit case)?  Any suggestions?

And yes, I'll expand tests/convenience.at to cover this
(as well as using something like `-export-symbols-regex *' optionally).

This issue has been reported by Brian Barrett against branch-1-5, but is
present in all Libtool branches, with the different facets shown above.

Cheers,
Ralf