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

[Gary V. Vaughan]

Hi Bob,

On 10 Oct 2012, at 21:09, Bob Friesenhahn <address@hidden> wrote:
> On Wed, 10 Oct 2012, Gary V. Vaughan wrote:
>> 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.

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)