Static libraries not following the libfoo.a naming convention

[Peter Rosin]

Hi!

I have been wondering when I was going to run into this problem, and
now it has happened (in the Libtool testsuite, tests/demo-deplibs.test).

Automake has rules for creating static libraries like so (taken from
that test case):

EXTRA_LIBRARIES = libhell0.a
libhell0_a_SOURCES =
libhell0_a_LIBADD = hello.$(OBJEXT) foo.$(OBJEXT)

That will create rules to create libhell0.a. The test case then has
rules for consuming that library, like so:

EXTRA_LTLIBRARIES = libhell1.la libhell2.la
libhell1_la_SOURCES = hell1.c
libhell1_la_LIBADD = -L. -lhell0
libhell1_la_LDFLAGS = -no-undefined -rpath $(libdir)
libhell1_la_DEPENDENCIES = libhell0.a
libhell2_la_SOURCES = hell2.c
libhell2_la_LIBADD = -L. -lhell0
libhell2_la_LDFLAGS = -no-undefined -rpath $(libdir)
libhell2_la_DEPENDENCIES = libhell0.a

"-L. -lhell0" is the key here. That is expected to pick up libhell0.a,
also notice the *_DEPENDENCIES, which lists the expected library file
name explicitly.

Now, that was all familiar territory, enter MS tools...

MS tools do not expect libraries to end with .a, and the convention
is to not prefix the library name with lib.  Which is why the compile
script, when used as MSVC wrapper, translates -lhell0 into hell0.lib
(and not libhell0.a).  Side note, Libtool creates static archives with
the hell0.lib form for MSVC.

compile *could* be extended to also look for the libhell0.a form, but
that is not really pretty, the compiler driver will say stuff like:

$ cl -nologo hell.obj libhell0.a
cl : Command line warning D9024 : unrecognized source file type 'libhell0.a', 
object file assumed

It works though, so that's the easy out I suppose. But me not like.
Libraries should simply not be named libhell0.a on this platform.

Would it be possible for Automake to create static libraries of the
hell0.lib form, when it sees "*_LIBRARIES = libhell0.a"? Since there
might be 3rd party dependencies assuming the libhell0.a form, it
might be good if Automake also copied the hell0.lib file to
libhell0.a after creating libraries of the hell0.lib form to satisfy
those dependencies. (Or a symlink might suffice?)

Cheers,
Peter