bug#12613: Subordinate libltdl builds convenience library when it should build shared library

[Bob Friesenhahn]

On Wed, 10 Oct 2012, Gary V. Vaughan wrote:

> Hi Bob,
>
> What revision of Libtool?

The released version 2.4.2.

> On Oct 10, 2012, at 9:31 AM, Bob Friesenhahn <address@hidden> wrote:
> > Ltdl is configured like
> >
> > LTDL_INIT([convenience nonrecursive])
>             ^^^^^^^^^^^
>
> > I noticed that all of the libltdl objects are being included into 
> > my library at link time and that libltdl symbols are being included 
> > my library's .exp exports file.  This is in spite of requesting 
> > that the libltdl library be built and installed.
>
> It seems that specifying a convenience library in configure.ac takes 
> precedence over specifying an installable (i.e. not-convenience) on 
> the command line.  I can't find any documentation to confirm or deny 
> that... when we've decided the precedence, we need to document it.

This same logic used to work as expected (at least from what I 
remember).  I am likely wrong though and perhaps this AIX linkage 
error (which is another bug) simply drew my attention to the problem.

What I was expecting is that if there is already an installed libltdl 
and the user has not specified --enable-ltdl-install that the 
installed libltdl is used.  If --enable-ltdl-install is specified then 
an installable version of libltdl should be built (and used).  If 
libltdl is not installed and the user has not specified 
--enable-ltdl-install, then it should be built as a convenience 
library and absorbed into the using application/library.

> Does it work the way you expect if you remove the convenience declaration from 
> the LTDL_INIT invocation?

A quick test (under OpenIndiana) with

LTDL_INIT([nonrecursive])

reveals that libltdl is still being built as a convenience library 
when libltdl is already installed and no special configure options 
were provided.  However, the build is correctly using the installed 
libltdl so there is no harm.

If I then configure with --enable-ltdl-install, I see that libltdl is 
being built as a shared library but there is a bug in that the 
dependent software is being told to link with already installed 
/usr/local/lib/libltdl.la rather than the uninstalled libltdl in the 
build tree.

If I configure with --enable-ltdl-install --with-included-ltdl then we 
are back to building a convenience library, with all libltdl symbols 
added to my program's main library (and exported, evil).  In this case 
it is in spite of an already installed libltdl.

Regardless, I don't see how bundled libltdl could work as hoped if the 
user forgets to add --enable-ltdl-install to the options.  Instead the 
user might get a successful build, but software which does not run 
after installation because the libltdl it was linked with is missing.

Bare machines without libltdl are pretty rare these days, and removing 
libltdl (for testing) might cause the system to to stop functioning 
normally.

It seems that bundling libltdl is a pox to my package.  In spite of 
supporting libldtl as a convenience library, since its symbols get 
added to my program's main library (usable by other software) there is 
a problem since it includes and exports libltdl symbols and might 
conflict with some libltdl installed later.

It is a bit of a problem that libltdl is not its own stand-alone 
package and is instead part of libtool.  Since it is part of libtool, 
it is necessary to install autoconf in order to install libtool (and 
thereby libltdl).  If libltdl was to be unbundled from my application, 
I would not want to have to tell the user that they need to install 
latest GNU m4, autoconf, and libtool in order to be able to use 
modules.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/