Hi all,
Libtool is a great tool, and it fits nicely with automake and autoconf,
making it extremely simple to just take a new project, write a few (less
than 10) lines to instructions, and get a project that already builds
static and shared libraries, including support for cross build, out of
tree builds, make install/uninstall, strip and even packaging the
sources into a distribution tar ball. Just great.
Except...
I have a problem. The libtool/automake duo, in an attempt to educate the
developer crowed, forces you to create a library of the form
"libsomething.so.v.v.v" (where the v's are version numbers). It has no
other form. As far as standard libraries go, this is not such a huge
problem. It does become a problem in some border cases.
Case in point: You want to develop a mozilla plugin. It is harmless but
makes no sense to have the plug-in's name begin with "lib". Also, if the
plugin's name does not end in ".so", Mozilla will refuse to load it.
Worse, Mozilla explicitly resolves symbolic links, so merely putting the
file name as libtool created it (libplugin.so.0.1.2) and placing a
symbolic link to it will not work. The file has to actually be called
"libplugin.so".
Here's the question - is it possible to tell the duo to not be so anal
about the whole thing? I want to create a project that will allow me to
use automake and libtool to create shared objects, but not force me to
name them with "lib" at the beginning and the API version number at the
end. Is it possible?
Alternatively, I would like to use only automake, let go of using
libtool, and do the same. Problem is, automake has several types of
programs it builds. These are PROGRAMS for executables, LIBRARIES for
static libraries, DATA for just data, LTLIBRARIES for libraries built
through libtool, and a few other non-built files. It does not have ANY
support for custom build types. The closest I got was:
plugindir = $(libdir)/mozilla/plugins
plugin_LIBRARIES = plugin.so
plugin_so_SOURCES = plugin.c
plusing_so_CFLAGS = -fpic
plugin.so: $(plugin_so_OBJECTS) $(plugin_so_DEPENDENCIES)
-rm -f plugin.so
$(CC) -shared $(plugin_so_OBJECTS) -o $@
While not horrible, that last rule is a clean copy of the same rule as
automake would have created, replacing the static library build rule
with a shared library build rule. It works, but each time anything is
updated I get the error:
Makefile.am:3: `plugin.so' is not a standard library name
Makefile.am:3: did you mean `libplugin.a'?
Again, the question is whether there is a way to make automake less anal
about the whole thing?
Thanks,
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
