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

From: "Gary V. Vaughan" <[email-masked]>
Date: Wed, 10 Oct 2012 21:43:14 +0700

Hi Bob,

On 10 Oct 2012, at 21:09, Bob Friesenhahn <[email-masked]> wrote:
> On Wed, 10 Oct 2012, Gary V. Vaughan wrote:
>> On Oct 10, 2012, at 9:31 AM, Bob Friesenhahn <[email-masked]> 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.

I assume you are using run-time linking on AIX?  I find almost all free software requires CFLAGS=-brtl.

> 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.

That's a reasonable mode of operation.

Would you mind writing a patch to our docs, and adding an appropriate XFAIL test to tests/configure-iface.at in the vein of the other tests cases in that file that link against an already installed libltdl?  We need to be completely clear about the semantics of --enable-ltdl-install both with and without an already installed libltdl, and what changes when --with-included-ltdl and/or --enable-ltdl-convenience (and their LTDL_INIT equivalents).  Also what is the precedence between LTDL_INIT options supplied by the developer, and configure-time options supplied by the package builder.  I tend to think LTDL_INIT should set the defaults, which can then be changed with configure-time options.

Given a proper description of how all these things should interact, and a test case or two to get me started, I'll be happy to chase down the first bug from there, and we can then analyse the other one in isolation afterwards.  Feel free to raise a separate bug report if you want to be sure we don't lose it.

>> 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.

Yuck, that sound completely fubar :(  How come no-one else noticed this bug after a year in the wild! :-o

> 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.

That seems like the correct behaviour to me, your package should use the system libltdl if it is new enough unless you specificaly request the bundled version.

> 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.

The exported symbols are another bug entirely :(  Let's push that one back until we solve the other two, first.  Again, feel free to raise a new bug report to track that one too.

> 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.

I think that without --enable-ltdl-install, it makes sense to roll the bundled libltdl as a convenience library.

> 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.

No need to install autoconf or GNU m4 to build a distributed libtool tarball, just ./configure && make all check && sudo make install.

Nonetheless, I've been musing about the pros and cons of separating libltdl into a separate package, mostly to try to simplify libtool itself enough that we can merge it into automake-ng or gnulib... and also because despite several years of pecking away at it, libltdl is neither pleasant to work with, or very well architected, so it would be nice to have the option to write a complete replacement without worrying about fitting into the libtool release schedule.  I think that decoupling would also make it much easier for GraphicsMagick and others to just depend on (new-enough) installed system libltdl, and fix your problems.

I'm very open to discussion on those possibilities on the appropriate lists.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)