.so extension
GNU Libtool supports an extremely wide variety of different platforms,
some of which do not use the .so extension for shared
libraries you might be used to on the Linux platform.
The decision as to which extension is correct for your system is made
during your package's configure script during the
AC_PROG_LIBTOOL macro. The correct result for Debian
systems is always “.so”.
If you've been directed to read this page then this isn't being correctly chosen, and most likely no shared extension has been chosen at all.
This is almost certainly not caused by incorrect detection of your
system, but by a bad update of the Libtool code within your package.
The AC_PROG_LIBTOOL macro is responsible for detecting
your system and generating a working libtool script for it.
It does this by attaching blocks of variables to the top and bottom of
the ltmain.sh file in your source package.
The ltmain.sh file is placed there and updated using the
libtoolize tool in the Libtool package. However, the
AC_PROG_LIBTOOL macro code doesn't get updated with this
tool. It's contained in the libtool.m4 file in your
/usr/share/aclocal directory; aclocal,
a tool that comes with GNU Automake, identifies all the macros your
configure.in file uses and concatenates all the files
together into the aclocal.m4 in your source package which
is then used by the autoconf tool to generate your final
configure script.
If ltmain.sh is updated, but the required chain of steps
to update the configure script to use the
AC_PROG_LIBTOOL macro code from the same version are not
performed, problems can occur. If the variable name ltmain.sh
expects is different from the one generated, the resulting
libtool script will not function correctly.
The most common visible effect of this mismatch is that your shared libraries will be generated without the correct file extension.
In order to cure this problem for your package you will need to update the version of Libtool it uses. This document explains how to do that.
Copyright © 2004 Scott James Remnant <scott@netsplit.com>.