bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary V. Vaughan
Subject: bug#18917: --disable-static breaks unittests (runpath-in-lalib.at & need_lib_prefix.at)
Date: Sun, 2 Nov 2014 18:28:41 +0000

Hi Mike,

> On Nov 1, 2014, at 2:54 AM, Mike Frysinger <address@hidden> 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)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]