GNU bug report logs - #19370
LT 2.4.4 regression (vs. 2.4.2)

Previous Next

Full log

View this message in rfc822 format

From: Pavel Raiskup <praiskup <at> redhat.com>
To: "Gary V. Vaughan" <gary <at> vaughan.pe>
Cc: jsquyres <at> cisco.com, 19370 <at> debbugs.gnu.org
Subject: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))
Date: Fri, 16 Jan 2015 15:34:54 +0100

On Friday 16 of January 2015 13:26:00 Gary V. Vaughan wrote:
> > On Monday 22 of December 2014 21:22:01 Gary V. Vaughan wrote:
> > - when libltdl is included into project as 'convenience' library, it is
> >  treated like "subproject".  Then running autoreconf from project's
> >  $(top_srcdir) treats subprojects independently by recursing down into
> >  subdirectory (in our case libltdl) and autoreconfing there.
> 
> Not always.  There is the full subproject mode, but also recursive and
> nonrecursive modes that hooks into the parent project's configure.ac (and
> Makefile.am in the latter case).
> 
> Is it only subproject libltdl (the one with its own configure.ac) that
> exhibits this bug?

I bet this particular bug yes.  But that is something I can not say
surely.  Switching to LTDL_INIT([nonrecursive]) works fine for me.

> >  The child autoreconf does not expect that something defined in parent
> >  directory will touch subdirectories after successful autoreconf.
> > 
> >  When parent autoreconf finished with autoreconfing of subdirectory, it
> >  continues in cwd - and that includes running libtoolize; _however_, this
> >  second run of libtoolize from top-level overwrites the _common_ macros.
> >  Now, the macros are more recent than the "subdirectory thinks".
> > 
> >  After that ^^^, the aclocal tool is run in top-level directory - but it
> >  has no idea about recursing down into (otherwise independent)
> >  subdirectory.  So everything happens as expected, two separate
> >  directories were autoreconfed independently.
> 
> Eventually (and by "eventually" I mean I've been planning for a long time,
> but haven't got to it yet) I'd like to get rid of the whole concept of
> carrying a local libltdl.  Libtool is now pervasive enough in the ecosystem,
> that it would be massively more straight forward if libltdl were just treated
> like any other dependency... i.e. if your project needs it, just install the
> proper version on your system first.
>
> We've long ignored the problem of what happens when linking, say, libm4.so
> with an internal copy of libltdl.so into an application that also uses the
> system libltdl.so, or worse wants to link with it's own subproject version.
> I'm sure distros have to jump through some hoops to make all of these clients
> simply agree on the system libltdl.so, which really is the only sane solution.
> The various subproject modes are an outdated idea from 20 years ago when
> libltdl didn't have any traction yet.
>
> [[snip]]
> 
> I think I'll try to release Libtool 2.4.5 later today, and then hack all the
> multi-mode libltdl subproject support out entirely for the next release, which
> neatly sidesteps the trickle of bugs caused all the little subtle interactions
> between the various generated files.

TBH, this is something I have no strong opinion on.  Seems like there is
no big benefit at least for GNU/Linux.  Maybe going through some
obsoleting process could help .. but I need to study more to discuss.

Pavel

Previous Next

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