bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))

[Gary V. Vaughan]

> On Jan 16, 2015, at 12:18 PM, Pavel Raiskup <address@hidden> wrote:
> 
> Hi Gary, quite long, sorry for that,


Hi Pavel,

Not in the least, the issue is convoluted, and I'd rather have long and
clear than terse and ambiguous! :-)  Thank you for making the time to
analyse the issue and propose some solutions!

> On Monday 22 of December 2014 21:22:01 Gary V. Vaughan wrote:
>> tags 19370 notabug
>> close 19730
>> 
>> On Dec 20, 2014, at 11:18 AM, Jeff Squyres (jsquyres) <address@hidden> wrote:
>>> Hopefully that's enough to get you going in the right direction.
>> 
>> Indeed it is.  And the problem is that autoreconf, as called from the
>> autogen.sh in the tarball, still runs the tools in the wrong order.
>> Autoreconf stupidly runs aclocal first, and then calls libtoolize which
>> adds more m4 files to AC_CONFIG_MACRO_DIR, and that in turn causes
>> aclocal.m4 to be out of date (because it needs to be regenerated to pick
>> up the local versions of the libtoolize added m4 files added to
>> ../config/ after it was first generated).
> 
> actually, (at least modern enough) autoreconf runs the aclocal twice.
> Once before libtoolize call (do detect whether it should call the
> libtoolize tool at all) and second time [1] after libtoolize to
> incorporate the macros.

That's good to know.  I stopped closely following autoconf development a
few years ago, and didn't realise this was finally cleaned up.  Some of
these corner case may be because of my slightly out of date view of how
these tools interact :-(

> I'd like to say in advance that IMO this should be fixed in libtoolize,
> somehow, reasoning follows.
> 
> - autoreconf is really generally believed to be the "tool #1" for
>  regenerating GNU buildsystem .. if we don't take the 'gnulib' or others
>  into account of course;  then however bootstrap comes and autoreconf
>  -vfi should still be OK

Agreed.

> - thus either libtool or autoreconf should be fixed, ..
> 
> - 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?

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

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