GNU bug report logs - #12613
Subordinate libltdl builds convenience library when it should build shared library

Previous Next

To reply to this bug, email your comments to 12613 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Libtool Bugs List <bug-libtool <at> gnu.org>
Subject: Subordinate libltdl builds convenience library when it should build
	shared library
Date: Tue, 9 Oct 2012 21:31:02 -0500 (CDT)

GraphicsMagick builds libltdl non-recursively as a subordinate 
component by including its Makefile.inc and using the ${LIBLTDL} and 
${LTDLDEPS} values it produces in the configure script.

Ltdl is configured like

LT_CONFIG_LTDL_DIR([ltdl])
LTDL_INIT([convenience nonrecursive])

Today while testing with the IBM XLC compiler on an AIX machine which 
does not have libltdl installed, I noticed that GraphicsMagick was 
unable to link, with this error:

1586-281 (E) A type mismatch was detected for symbol "dlopen_LTX_get_vtable".

This issue is noticed with and without the --enable-ltdl-install 
option supplied.  The --enable-ltdl-convenience option was not 
supplied.

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 libltdl was built as a static library rather than a 
shared library and it is being used as a convenience library 
(libltdlc.a) rather than being used as a (to be installed) shared 
library dependency as it should be.

The build was configured with

  --enable-shared --disable-static --enable-ltdl-install

so it seems that libltdl should have been built as a shared library.

Here is relevant configure output:

checking how to hardcode library paths into programs... immediate
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... yes
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether we are using the GNU C++ compiler... no
checking whether xlC_r accepts -g... yes
checking dependency style of xlC_r... xlc
checking how to run the C++ preprocessor... xlC_r -E
checking whether the xlC_r linker (/bin/ld) supports shared libraries... yes
checking for xlC_r option to produce PIC...  -DPIC
checking if xlC_r PIC flag  -DPIC works... yes
checking if xlC_r static flag -bnso -bI:/lib/syscalls.exp works... no
checking if xlC_r supports -c -o file.o... yes
checking if xlC_r supports -c -o file.o... (cached) yes
checking whether the xlC_r linker (/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... aix7.1.0.0 ld.so
checking how to hardcode library paths into programs... immediate
checking which extension is used for runtime loadable modules... .so
checking which variable specifies run-time module search path... LIBPATH
checking for the default library search path... /lib /usr/lib
checking for library containing dlopen... none required
checking for dlerror... yes
checking for shl_load... (cached) no
checking for shl_load in -ldld... (cached) no
checking for dld_link in -ldld... no
checking for _ prefix in compiled symbols... no
checking whether deplibs are loaded by dlopen... yes
checking for argz.h... no
checking for error_t... no
checking for argz_add... no
checking for argz_append... no
checking for argz_count... no
checking for argz_create_sep... no
checking for argz_insert... no
checking for argz_next... no
checking for argz_stringify... no
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for ltdl.h... no
checking where to find libltdl headers... -I${top_srcdir}/ltdl
checking where to find libltdl library... ${top_build_prefix}ltdl/libltdlc.la

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #8 received at 12613 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: "12613 <at> debbugs.gnu.org" <12613 <at> debbugs.gnu.org>
Subject: Re: bug#12613: Subordinate libltdl builds convenience library when it
	should build shared library
Date: Wed, 10 Oct 2012 10:29:48 +0700

Hi Bob,

What revision of Libtool?

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.

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

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

Message #11 received at 12613 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: "12613 <at> debbugs.gnu.org" <12613 <at> debbugs.gnu.org>
Subject: Re: bug#12613: Subordinate libltdl builds convenience library when
	it should build shared library
Date: Wed, 10 Oct 2012 09:09:33 -0500 (CDT)

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/

Message #14 received at 12613 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: "12613 <at> debbugs.gnu.org" <12613 <at> debbugs.gnu.org>
Subject: Re: bug#12613: Subordinate libltdl builds convenience library when it
	should build shared library
Date: Wed, 10 Oct 2012 21:43:14 +0700

Hi Bob,

On 10 Oct 2012, at 21:09, Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> wrote:
> On Wed, 10 Oct 2012, Gary V. Vaughan wrote:
>> 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.

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)

Message #17 received at 12613 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: "12613 <at> debbugs.gnu.org" <12613 <at> debbugs.gnu.org>
Subject: Re: bug#12613: Subordinate libltdl builds convenience library when
	it should build shared library
Date: Wed, 10 Oct 2012 11:14:02 -0500 (CDT)

On Wed, 10 Oct 2012, Gary V. Vaughan wrote:
>
> I assume you are using run-time linking on AIX?  I find almost all free software requires CFLAGS=-brtl.

Yes.  The GraphicsMagick configure script is automatically adding it.

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

No that is the wrong behavior since the application is linked with a 
libltdl different than the one that it is installing.  It should link 
against the libltdl that it is installing.  Anything else is a bug.

I think that supporting installing a bundled libltd is a bug.  It is a 
very dangerous feature.  The dangers become very evident after one 
does 'make uninstall' after doing 'make install' on a system which 
already included the same version of libltdl so previously-existing 
libltdl is now completely deleted.

Linking a libltdl convenience library into a library to be installed 
is also a bug.

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

Ok, better than I thought.  But still libtool stuff gets installed 
when the user only intended/needed to install libltdl.

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

At this point in time I am thinking about stripping bundled libltdl 
out of GraphicsMagick and treating libltdl like any other library that 
it optionally depends on.

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

Yes, feature discussions do not belong here.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #20 received at 12613 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: bug-libtool <at> gnu.org, "12613 <at> debbugs.gnu.org" <12613 <at> debbugs.gnu.org>
Subject: Re: bug#12613: Subordinate libltdl builds convenience library when
	it should build shared library
Date: Thu, 11 Oct 2012 09:18:43 -0500 (CDT)

On Wed, 10 Oct 2012, Bob Friesenhahn wrote:

> On Wed, 10 Oct 2012, Gary V. Vaughan wrote:
>> 
>> I assume you are using run-time linking on AIX?  I find almost all free 
>> software requires CFLAGS=-brtl.
>
> Yes.  The GraphicsMagick configure script is automatically adding it.

I did some more investigation and found that my above statement was 
incorrect.  The GraphicsMagick configure script is not automatically 
adding -brtl to LDFLAGS, rather, I have a wrapper script used on the 
build machine which is passing -brtl via LDFLAGS to the configure 
script.  This option is then properly used while compiling the 
GraphicsMagick objects, but LDFLAGS is being ignored while building 
libltdl.  Ignoring user-provided LDFLAGS seems unkind.

Libltdl's Makefile.inc makes no reference to LDFLAGS (ignores it) but 
it respects AM_LDFLAGS.  The GraphicsMagick Makefile.am declares a 
starting AM_LDFLAGS which is empty, and then libltdl's Makefile.inc 
fragment adds to this via += syntax.

Regarding a correctly installable libltdl, I am experimenting with 
initializing libltdl like

LTDL_INIT([nonrecursive installable])

and this seems to help in that a convencience library is not copied 
into the application library.  I am not sure what the ramifications of 
this change to users would be though.

I am thinking that I should delay the forthcoming release of my 
software and take the time to unbundle libltdl because bundling is 
clearly not helping in any way.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.