GNU bug report logs -
#12613
Subordinate libltdl builds convenience library when it should build shared library
Previous Next
Full log
View this message in rfc822 format
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 <bfriesen <at> simple.dallas.tx.us> 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
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
This bug report was last modified 12 years and 259 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.