Subject: bug#18917: --disable-static breaks unittests (runpath-in-lalib.at & need_lib_prefix.at)

From: "Gary V. Vaughan" <[email-masked]>
Date: Sun, 2 Nov 2014 18:28:41 +0000

Hi Mike,

> On Nov 1, 2014, at 2:54 AM, Mike Frysinger <[email-masked]> wrote:
> 
> when you configure libtool with --disable-static, these two unittests fail:
> 	runpath-in-lalib.at
> 	need_lib_prefix
> 
> if you hack the libtool script to set build_old_libs=yes by default, then the 
> unittests pass.  it looks like libtool has flags to enable building of either 
> static or shared libs, but there's no way to make it build both (which is the 
> default with --enable-{shared,static}).
> 
> along those lines, it'd be nice if --disable-static didn't do this to the local 
> copy of libtool that gets installed.  i understand the relationship between the 
> configure flags and the generated libtool script -- normally you use the local 
> libtool build the local libs and then only install those libs.  this is even how 
> it's used with libltdl.  but the libtool package itself is a bit special in that 
> it also installs the libtool script.

Yeah.  We're conflating the flags for building libltdl with the flags for the
libtool used to build it.

But, I don't see a sensible straight-forward way of fixing it.  Really, we need
to have libltdl build it's own libtool based on the configure flags, and have
libtool proper generate a separate installable libtool.  But that's a whole can
of worms I don't want to open, and was part of the reason I made plans to split
the existing libtool into 2 separately distributed packages in the next major
release:  Then, it would be obvious that configuring the package that installs
bin/libtool with --disable-static really is installing a libtool that has static
library building turned off by default.

> in Gentoo atm, i'm hacking this by setting build_old_libs=yes in the generated 
> libtool script before testing/installing.  but ideally it'd be possible to 
> install `libtool` with settings based on what the system can do, not how the 
> package is building libltdl.{a,so}.

I think it would be safer for gentoo to package the two separately then... have a
libltdl package, which you build using --disable-static, and a separate libtool
package (containing libtoolize, libtool and the supporting share/libtool files)
configured with --enable-shared and --enable-static.

I'd be very happy to receive a patch to fix things more elegantly (perhaps by
adding additional flags to the top-level configure, and massaging and filtering
what gets passed down to a sub-configure in the libltdl subdirectory), but I'm
afraid I don't have the time to make it happen myself in the immediate future :(
Especially considering that the better long term fix is to split libltdl out into
its own project.

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