libtool and cl

[Braden McDaniel]

Has anyone in earshot here given any thought to what it might take to fix
libtool's cl (Microsoft Visual C++ compiler) support? I have an interest in
fixing this, and I'm in the process of poking around to see what it's gonna
take. I am far from an expert on MS Windows libraries; but I'm prepared to
fake it.

The stickiest point I've found so far is that "libname.lib" can refer either
to a static library, or an "import library" that is associated with a DLL.
This has two significant ramifications for libtool:

 * libtool's current assumption that "libname.lib" when it appears on the
command line refers to a static library is not valid. But because there's no
syntactic difference in the way import libraries and static libraries are
specified to cl, libtool should simply proceed regardless. This doesn't seem
hard to address.

 * When building both static and shared (DLL) libraries, there will be a
problem in that the import library created along with the DLL will have the
same name as the static library. The static library could be disambiguated,
of course; but that raises the question of whether the disambiguation should
be applied silently by libtool to try to locate a library prior to linking.
For example, if the disambiguation of "foo.lib" results in "libfoo.lib",
should libtool convert a reference to "foo.lib" on the command line to
"libfoo.lib" if "foo.lib" cannot be found?

The latter issue stands to get into munging command line parameters. If
libtool Goes There, then perhaps it should just accept POSIX-style -l
parameters instead and convert them into things cl understands.

Thoughts?

--
Braden McDaniel <address@hidden>
Software Engineer, Object Sciences Corporation