Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hi Eric,

Thanks for trying this out with m4, you beat me to the punch :-)

On 23 Jan 2008, at 22:00, Eric Blake wrote:


The problem seems to stem from the fact that I had an older version of
libltdl copied into my M4 tree, and autoreconf runs aclocal prior to
libtoolize, so it was picking up the old definition of LTDL_INIT which
conflicted with my new contents of configure.ac.


Hmm.  I need to find a way to diagnose that properly.  Thanks for the
detective work!


By the way, shouldn't libtoolize be taught to parse LTDL_INIT out of
configure.ac, rather than requiring the user to supply the -- 
nonrecursive

command-line option?



Actually, it used to do that.  I guess I broke it when I started moving
the options around.  I'll fix this before the alpha release too.

Cheers,
Gary
--
Gary V. Vaughan ([EMAIL PROTECTED])





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Eric Blake on 1/22/2008 11:30 PM:
| However, autoreconf -fi now complains:
|
| autoreconf: running: aclocal --force -I ltdl/m4
| configure.ac:92: error: multiple libltdl directories: `ltdl',
| `nonrecursive convenience'
| ltdl/m4/ltdl.m4:23: _LT_CONFIG_LTDL_DIR is expanded from...
| ltdl/m4/ltdl.m4:242: LTDL_INIT is expanded from...
| configure.ac:92: the top level
|
| Somehow, it is trying to treat the arguments to LTDL_INIT as a directory
| name, rather than options.

The problem seems to stem from the fact that I had an older version of
libltdl copied into my M4 tree, and autoreconf runs aclocal prior to
libtoolize, so it was picking up the old definition of LTDL_INIT which
conflicted with my new contents of configure.ac.

By the way, shouldn't libtoolize be taught to parse LTDL_INIT out of
configure.ac, rather than requiring the user to supply the --nonrecursive
command-line option?  Neither 'libtoolize -f -i' nor 'libtoolize -f -i
- --nonrecursive' was enough:

$ libtoolize -f -i --nonrecursive
...
$ autoreconf -v
...
autoreconf: running: automake --no-force
automake: cannot open < ltdl/Makefile.inc: No such file or directory
autoreconf: automake failed with exit status: 1


I had to supply --ltdl to libtoolize before Makefile.inc was created.
Also, libtoolize is smart enough to parse AC_CONFIG_AUX_DIR out of
configure.ac, and begins installing several files there.  However, with
the --ltdl option, it then proceeds to install additional copies of files
into ltdl/config, rather than reusing what it already learned:

$ libtoolize -f -i -c --nonrecursive --ltdl=ltdl
libtoolize: putting files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/config.guess'
...
libtoolize: copying file `ltdl/argz.c'
...
libtoolize: copying file `ltdl/config/compile'
libtoolize: copying file `ltdl/config/config.guess'
...
libtoolize: Consider using `AC_CONFIG_AUX_DIR([ltdl/config])' in configure.ac.


Why can't it put all the files in build-aux, rather than some files only
in ltdl/config and duplicates of other files in both directories?  I can
understand its placement of files for a subproject build (where ltdl needs
to be a self-contained project), but for nonrecursive, it would be nicer
for libtoolize to fit in with the rest of the package it is being
integrated into.  Which brings up the next problem - even with the above
invocation, autoreconf still chokes:

$ autoreconf -v
...
autoreconf: running: automake --no-force
configure.ac:250: required file `gnu/lt__dirent.c' not found
configure.ac:250: required file `gnu/argz.c' not found
configure.ac:250: required file `gnu/lt__strl.c' not found
autoreconf: automake failed with exit status: 1

Automake is looking inside AC_CONFIG_LIBOBJ_DIR (gnu) rather than where
libtoolize installed those files (ltdl).  I'm still not sure what to do
about that, although it probably will be similar to how gnulib supports
dual libraries (such as one library containing --lgpl objects, the other
containing GPL).  My understanding was that gnulib plays some m4 games
with m4_pushdef(AC_LIBOBJ) to achieve the right effect

I guess this thread means autoreconf will also need to be taught about
libtoolize's new modes; also autoconf and automake could probably be
improved in their handling of multiple LIBOBJ directories.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHl0iH84KuGfSFAYARAgcpAKCEqv+3oNY3p14N/FcapNxwhCjwLACfZDTc
g1NeuktSjVUNl7n5IZUaxqY=
=4n7I
-END PGP SIGNATURE-

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 1/7/2008 1:40 PM:
|
| Well, I finally got done with my look over this, so you may want to
| consider it first.  And when you're done and bored again, I will post a
| few test failures to ponder over, ok?  ;-)

I haven't looked at this patch in detail, but I decided to give it a spin
and convert M4 head to use nonrecursive mode.  Following the examples from
the documentation, I updated configure.ac to include this snippet:

LT_PREREQ([2.1a])
LT_CONFIG_LTDL_DIR([ltdl])
LT_INIT([shared dlopen win32-dll])
LTDL_INIT([nonrecursive convenience])

However, autoreconf -fi now complains:

autoreconf: running: aclocal --force -I ltdl/m4
configure.ac:92: error: multiple libltdl directories: `ltdl',
`nonrecursive convenience'
ltdl/m4/ltdl.m4:23: _LT_CONFIG_LTDL_DIR is expanded from...
ltdl/m4/ltdl.m4:242: LTDL_INIT is expanded from...
configure.ac:92: the top level

Somehow, it is trying to treat the arguments to LTDL_INIT as a directory
name, rather than options.

Since you are more familiar with the recent Libtool patch: Any ideas why,
or how to fix libtool to recognize that M4 is using a custom name for the
libtool files (ltdl, not libltdl)?  I may get around to it, but it will
take me longer to come up to speed.

At any rate, here's the current state of the patch for M4, for reproducing
this.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHlt8g84KuGfSFAYARAqmsAKCC6prQoOOeIwZn+Reexi+1ClwjkgCfWmQd
v36u3TCtxxDdm4uMUSUC2lI=
=aq/5
-END PGP SIGNATURE-
>From eb2b6bd0ab38a390a2d7cab4b43e3872391907cc Mon Sep 17 00:00:00 2001
From: Eric Blake <[EMAIL PROTECTED]>
Date: Tue, 22 Jan 2008 23:26:31 -0700
Subject: [PATCH] Update to latest libtool usage.

* configure.ac (LT_PREREQ): Require bleeding-edge libtool.  If the
user insists on an installed libtool, ensure it is new enough.
(LT_WITH_LTDL): Delete, obsoleted by libtool.
(LTDL_INIT): Call new libtool macro, select nonrecursive mode.
* Makefile.am (SUBDIRS): No longer build ltdl recursively.
(AM_CPPFLAGS): Rely on libtool for . and LTDLINCL.
(AM_LDFLAGS): Rely on libtool for -no-undefined.
(EXTRA_DIST, lib_LTLIBRARIES): Factor for appending.
(include_HEADERS, noinst_LTLIBRARIES, EXTRA_LTLIBRARIES): New
variables required by libtool.

Signed-off-by: Eric Blake <[EMAIL PROTECTED]>
---
 ChangeLog|   14 ++
 Makefile.am  |   36 
 configure.ac |   17 +++--
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b911528..771b228 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2008-01-23  Eric Blake  <[EMAIL PROTECTED]>
+
+   Update to latest libtool usage.
+   * configure.ac (LT_PREREQ): Require bleeding-edge libtool.  If the
+   user insists on an installed libtool, ensure it is new enough.
+   (LT_WITH_LTDL): Delete, obsoleted by libtool.
+   (LTDL_INIT): Call new libtool macro, select nonrecursive mode.
+   * Makefile.am (SUBDIRS): No longer build ltdl recursively.
+   (AM_CPPFLAGS): Rely on libtool for . and LTDLINCL.
+   (AM_LDFLAGS): Rely on libtool for -no-undefined.
+   (EXTRA_DIST, lib_LTLIBRARIES): Factor for appending.
+   (include_HEADERS, noinst_LTLIBRARIES, EXTRA_LTLIBRARIES): New
+   variables required by libtool.
+
 2008-01-22  Ralf Wildenhues  <[EMAIL PROTECTED]>
and Eric Blake  <[EMAIL PROTECTED]>
 
diff --git a/Makefile.am b/Makefile.am
index e79210c..76d0efc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,34 +23,46 @@
 config_aux_dir = build-aux
 config_macro_dir= ltdl/m4
 
-SUBDIRS= ltdl po gnu tests/gnu .
+SUBDIRS= po gnu tests/gnu .
 
 ACLOCAL_AMFLAGS = -I ltdl/m4
 AUTOMAKE_OPTIONS = nostdinc
-AM_CPPFLAGS= -I. -I$(srcdir) \
- -Ignu -I$(srcdir)/gnu \
- -Im4 -I$(srcdir)/m4 \
- $(LTDLINCL)
+
+# Prime variables that will be added to by libtool.
+AM_CPPFLAGS=
 # FIXME - the -export-symbols-regex ".*" is a hack to work around the
 # fact that on cygwin, the convenience library libltdl exports symbols,
 # which effectively disables the auto-exporting of all other symbols.
 # Revisit this if libtool on cygwin improves.
 # See http://lists.gnu.org/archive/html/libtool-patches/2007-02/msg00062.html
-AM_LDFLAGS = -no-undefined -export-dynamic -export-symbols-regex ".*"
+AM_LDFLAGS = -export-dynamic -export-symbols-regex ".*"
+
+BUILT_SOURCES  =
+EXTRA_DIST =
+CLEANFILES =
+MOSTLYCLEANFILES=
+
+include_HEADERS=
+noinst_LTLIBRARIES=
+lib_LTLIBRARIES=
+EXTRA_LTLIBRARIES=
 
-EXTRA_DIST = bootstrap \
+# Include Libtool's rules.
+include ltdl/Makefile.inc
+
+# Add

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Thu, Jan 17, 2008 at 06:20:31AM CET:
> On 17 Jan 2008, at 03:37, Ralf Wildenhues wrote:
> >OK to apply this patch to fix it and some other cases?
> 
> Yes please.

Done as below, thanks.

> Our libtoolize test coverage is still extremely poor.  When you commit
> could you also please add a TODO for writing a test case that adds the
> libtool macros to aclocal.m4?

Yep.

Cheers,
Ralf

2008-01-17  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libtoolize.m4sh (func_scan_files): Avoid matching our own
macro code when scanning configure.ac and aclocal.m4.
Don't produce spurious output if AC_PROG_RANLIB is found.
* tests/old-m4-iface.at (AM_PROG_LIBTOOL): Add a (weak) check
that we don't match our own macro code when searching for user
code calling us.
* TODO: Updated.

Index: TODO
===
RCS file: /cvsroot/libtool/libtool/TODO,v
retrieving revision 1.73
diff -u -r1.73 TODO
--- TODO25 Mar 2007 12:12:42 -  1.73
+++ TODO17 Jan 2008 05:35:45 -
@@ -103,6 +103,8 @@
   processes per copied file, a list of files to copy is built and all
   files copied with a single pair of tar processes.
 
+* Write test case that adds libtool macros to aclocal.m4.
+
 
 2. In the future
 
@@ -278,7 +280,7 @@
   it easier to add new platforms.
 
 -- 
-  Copyright (C) 2004, 2005 Free Software Foundation, Inc.
+  Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
   Written by Gary V. Vaughan, 2004
 
   This file is part of GNU Libtool.
Index: libtoolize.m4sh
===
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.64
diff -u -r1.64 libtoolize.m4sh
--- libtoolize.m4sh 6 Jan 2008 16:33:30 -   1.64
+++ libtoolize.m4sh 17 Jan 2008 05:35:45 -
@@ -418,14 +418,18 @@
s,^.*LT_CONFIG_LTDL_DIR([[   ]*\([^])]*\).*$,ac_ltdldir=\1,
p
}
+   /\@<:@A[CM]_PROG_LIBTOOL/d
/A[CM]_PROG_LIBTOOL/ {
s,^.*$,seen_libtool=:,
p
}
+   /the.*option into.*LT_INIT.*parameter/d
+   /\@<:@LT_INIT/d
/LT_INIT/{
s,^.*$,seen_libtool=:,
p
}
+   /\@<:@LTDL_INIT/d
/LTDL_INIT/  {
s,^.*LTDL_INIT([[   ]*\([^])]*\).*$,ltdl_options="\1",
s,^.*LTDL_INIT[ ]*$,seen_ltdl=:,
@@ -960,7 +964,7 @@
 else
   # Don't trace for this, we're just checking the user didn't invoke it
   # directly from configure.ac.
-  $SED 's,dnl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB &&
+  $SED 's,dnl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB 
>/dev/null &&
 func_echo "\`AC_PROG_RANLIB' is rendered obsolete by \`LT_INIT'"
 fi
 
Index: tests/old-m4-iface.at
===
RCS file: /cvsroot/libtool/libtool/tests/old-m4-iface.at,v
retrieving revision 1.14
diff -u -r1.14 old-m4-iface.at
--- tests/old-m4-iface.at   12 Jan 2008 14:07:02 -  1.14
+++ tests/old-m4-iface.at   17 Jan 2008 05:35:45 -
@@ -86,6 +86,17 @@
 
 LT_AT_EXEC_CHECK([./old], 0, [Hello, World!])
 
+# Now, test that libtoolize doesn't mistakenly think the user called
+# any libtool macros if in fact she didn't.
+sed '/AM_PROG_LIBTOOL/d' configure.in >configure.int
+mv -f configure.int configure.in
+AT_CHECK([$LIBTOOLIZE -n], [0], [stdout], [stderr])
+# ensure no shell errors:
+AT_CHECK([grep -v "^libtoolize: " stderr], [1])
+AT_CHECK([grep "Remember to add.*LT_INIT.*to configure.in" stdout], [0], 
[ignore])
+AT_CHECK([grep "Consider adding.*LT_WITH_LTDL" stdout], [1])
+AT_CHECK([grep "Remember to add.*LT_CONFIG_LTDL_DIR" stdout], [1])
+
 AT_CLEANUP
 
 

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Thu, Jan 17, 2008 at 05:29:17AM CET:
> On 16 Jan 2008, at 14:22, Ralf Wildenhues wrote:
> >OK to apply?
> 
> I have some nits first.  Please commit once they are addressed.

Addressed and committed as noted below.  Thanks for your quick review.

> > * NEWS: Update.
> 
> Except for a couple of instances in the latest ChangeLog rotation, we've
> always used past tense here.  Super picky, I know, but we might as well
> strive for consistency.

Actually, it's a noun, or just active instead of passive voice.
FWIW, the GCS uses present tense in all their examples.  But hey,
I'm not attached to that.

> I'm also not sure about the name LIBLTDL_DEP, as it is visibly different
> to the other two, and also to existing PREOPEN_DEPENDENCIES and  
> INFO_DEPS,
> and gnulibs use of the '_DEPENDENCIES' suffix. I'd prefer either  
> LTDLDEPS
> (vis LTDLINCL) or LIBLTDL_DEPENDENCIES for consistency with prior art.

Be it LTDLDEPS then.

> Actually, now that I think about it, the user doesn't see these as shell
> variables at all, but as make macros.  It might be better to simply  
> refer to them as make macros to avoid any confusion.

But that would then be another independent change, yes?  Because it not
only touches the issue I'm fixing now, but also the other instances of
"shell variables" that were there earlier, from which I merely copied.
Would you please write this patch for me?  Thanks.

> >+AT_CHECK([$MAKE -q main$EXEEXT || exit 1], [1], [ignore], [ignore])
> >+
> 
> -q might not work with some of the makes that we support.  Safer to use:
> 
>   AT_CHECK([$MAKE main$EXEEXT >/dev/null 2>&1 || exit 1], ...

'make -q' is POSIX and works with make implementations from AIX 4.3.3
and up, HP-UX 10.20 and up, IRIX 6.5, Tru64 4.0D, FreeBSD, NetBSD,
OpenBSD, GNU, Solaris 6 and up.  Do you know one that doesn't support
it?  It should be mentioned in the Autoconf manual.  Note 'make -q' is
not like 'grep -q'.

Cheers,
Ralf

2008-01-17  Ralf Wildenhues  <[EMAIL PROTECTED]>

New variable LTDLDEPS for use in output_DEPENDENCIES.

* libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE, _LTDL_INSTALLABLE)
(LTDL_INIT): Set and substitute LTDLDEPS according to chosen
method.
* tests/configure-iface.at (installable libltdl)
(--with-ltdl-include/lib, --with-included-ltdl): Test it.
* doc/libtool.texi (Distributing libltdl): Document LTDLDEPS.
* NEWS: Updated.
Dependency bug exposed by Eric Blake in M4, found by Bob Proulx
build daemon.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.214
diff -u -r1.214 NEWS
--- NEWS12 Jan 2008 17:00:51 -  1.214
+++ NEWS17 Jan 2008 05:25:22 -
@@ -52,6 +52,7 @@
 The Libtool package itself builds libltdl nonrecursively.
   - The 'nonrecursive', 'recursive' and 'subproject' libltdl build
 modes are given as LTDL_INIT options.
+  - New make variable LTDLDEPS for use in output_DEPENDENCIES.
   - New multi-module-loader safe libltdl handle iteration APIs:
 lt_dlhandle_iterate, lt_dlhandle_fetch, lt_dlhandle_map.
   - New lt_dlinterface_register to maintain separation of concerns
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.236
diff -u -r1.236 libtool.texi
--- doc/libtool.texi17 Jan 2008 05:05:59 -  1.236
+++ doc/libtool.texi17 Jan 2008 05:25:25 -
@@ -,10 +,11 @@
 @option{--with-included-ltdl}.
 
 If an installed @code{libltdl} is found, then @code{LIBLTDL} is set to
-the link flags needed to use it, and @code{LTDLINCL} to the
-preprocessor flags needed to find the installed headers.  Note,
-however, that no version checking is performed.  You should manually
-check for the @code{libltdl} features you need in @file{configure.ac}:
+the link flags needed to use it, and @code{LTDLINCL} to the preprocessor
+flags needed to find the installed headers, and @code{LTDLDEPS} will
+be empty.  Note, however, that no version checking is performed.  You
+should manually check for the @code{libltdl} features you need in
[EMAIL PROTECTED]:
 
 @example
 LT_INIT([dlopen])
@@ -4588,7 +4589,7 @@
 to cause it to be built as a convenience library.  If you're not
 using automake, you will need to define @code{top_build_prefix},
 @code{top_builddir}, and @code{top_srcdir} in your makefile so that
[EMAIL PROTECTED] and @code{LTDLINCL} expand correctly.
[EMAIL PROTECTED], @code{LTDLDEPS}, and @code{LTDLINCL} expand correctly.
 
 One advantage of the convenience library is that it is not installed,
 so the fact that you use @code{libltdl} will not be apparent to the
@@ -4612,42 +4613,46 @@
 to cause it to be built as an installable library.  If you're not
 using automake, you will need to define @code{top_build_prefix},
 @code{top_builddir} and @c

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

On 17 Jan 2008, at 12:47, Ralf Wildenhues wrote:

However, I
am fairly confident that old libtool documentation recommended the
opposite order, and opposite order was likely required at that time.


I can't find any mention toward the relative order of AC_PROG_LIBTOOL
and AC_LIB_LTDL in branch-1-5's manual at all.  And AC_WITH_LTDL was  
not

mentioned at all.



AC_WITH_LTDL was an experiment that never really worked out.  I think we
did require pathological ordering at some point too, but as far as I'm
aware the interface never settled down enough to make it into the docs.

Cheers,
Gary
--
Gary V. Vaughan ([EMAIL PROTECTED])





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

On 17 Jan 2008, at 13:06, Ralf Wildenhues wrote:

* Gary V. Vaughan wrote on Thu, Jan 17, 2008 at 05:29:17AM CET:

On 16 Jan 2008, at 14:22, Ralf Wildenhues wrote:


Also clarify that `${top_build_prefix}' may be used in place of
`${top_builddir}/'.


This is a different patch.


Yes, it's instance 10/11 of cleaning up after patch 333.
Applied like this.



*blush*

I need to be more careful about the mego-patches I drop from time to  
time.

Apologies. :")

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_  Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

On 17 Jan 2008, at 03:37, Ralf Wildenhues wrote:

OK to apply this patch to fix it and some other cases?


Yes please.


2008-01-16  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libtoolize.m4sh (func_scan_files): Avoid matching our own
macro code when scanning configure.ac and aclocal.m4.
Don't produce spurious output if AC_PROG_RANLIB is found.
* tests/old-m4-iface.at (AM_PROG_LIBTOOL): Add a (weak) check
that we don't match our own macro code when searching for user
code calling us.



Our libtoolize test coverage is still extremely poor.  When you commit
could you also please add a TODO for writing a test case that adds the
libtool macros to aclocal.m4?

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_  Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Thu, Jan 17, 2008 at 05:29:17AM CET:
> On 16 Jan 2008, at 14:22, Ralf Wildenhues wrote:
> 
> > Also clarify that `${top_build_prefix}' may be used in place of
> > `${top_builddir}/'.
> 
> This is a different patch.

Yes, it's instance 10/11 of cleaning up after patch 333.
Applied like this.

Cheers,
Ralf

2008-01-17  Ralf Wildenhues  <[EMAIL PROTECTED]>
 
* doc/libtool.texi (Distributing libltdl): Clarify that
`${top_build_prefix}' may be used in place of `${top_builddir}/'.

Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.235
diff -u -r1.235 libtool.texi
--- doc/libtool.texi17 Jan 2008 04:47:40 -  1.235
+++ doc/libtool.texi17 Jan 2008 05:03:14 -
@@ -4639,15 +4639,15 @@
 @item
 If your package is built using the convenience libltdl, @var{LIBLTDL}
 will be the pathname for the convenience version of libltdl
-(starting with @[EMAIL PROTECTED]@}/}) and @var{LTDLINCL} will be
[EMAIL PROTECTED] followed by the directory that contains @file{ltdl.h}
-(starting with @[EMAIL PROTECTED]@}/}).
+(starting with @[EMAIL PROTECTED]@}/} or @[EMAIL PROTECTED]@}})
+and @var{LTDLINCL} will be @option{-I} followed by the directory that
+contains @file{ltdl.h} (starting with @[EMAIL PROTECTED]@}/}).
 
 @item
 If an installable version of the included @code{libltdl} is being
-built, its pathname starting with @[EMAIL PROTECTED]@}/}, will be
-stored in @var{LIBLTDL}, and @var{LTDLINCL} will be set just like in
-the case of convenience library.
+built, its pathname starting with @[EMAIL PROTECTED]@}/} or
[EMAIL PROTECTED]@[EMAIL PROTECTED], will be stored in @var{LIBLTDL}, and
[EMAIL PROTECTED] will be set just like in the case of convenience library.
 @end itemize
 
 You should probably also use the @samp{dlopen} option to @code{LT_INIT}

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Thu, Jan 17, 2008 at 01:17:58AM CET:
> On Wed, 16 Jan 2008, Ralf Wildenhues wrote:
> >
> >>However, as usual, I don't feel qualified to review other aspects
> >>of this patch...
> >
> >Well, thanks anyway for spotting this typo!
> 
> With this change, I am ok with the documentation updates.

Applied, thanks for the review.

> However, I 
> am fairly confident that old libtool documentation recommended the 
> opposite order, and opposite order was likely required at that time.

I can't find any mention toward the relative order of AC_PROG_LIBTOOL
and AC_LIB_LTDL in branch-1-5's manual at all.  And AC_WITH_LTDL was not
mentioned at all.

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

Thanks for the fast fixes!

On 16 Jan 2008, at 14:22, Ralf Wildenhues wrote:

OK to apply?


I have some nits first.  Please commit once they are addressed.


2008-01-16  Ralf Wildenhues  <[EMAIL PROTECTED]>

New variable LIBLTDL_DEP for use in output_DEPENDENCIES.
* libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE, _LTDL_INSTALLABLE)
(LTDL_INIT): Set and substitute LIBLTDL_DEP according to chosen
method.
* tests/configure-iface.at (installable libltdl)
(--with-ltdl-include/lib, --with-included-ltdl): Test it.
* doc/libtool.texi (Distributing libltdl): Document LIBLTDL_DEP.


Our ChangeLog standard says to write intro's like this:

New variable LIBLTDL_DEP for use in output_DEPENDENCIES:

* libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE, _LTDL_INSTALLABLE)
(LTDL_INIT): Set and substitute [[...]]


Also clarify that `${top_build_prefix}' may be used in place of
`${top_builddir}/'.


This is a different patch.


* NEWS: Update.


Except for a couple of instances in the latest ChangeLog rotation, we've
always used past tense here.  Super picky, I know, but we might as well
strive for consistency.


[[...]]



Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.234
diff -u -r1.234 libtool.texi
--- doc/libtool.texi6 Jan 2008 16:33:30 -   1.234
+++ doc/libtool.texi16 Jan 2008 06:21:06 -
@@ -4443,10 +4443,11 @@
@option{--with-included-ltdl}.

If an installed @code{libltdl} is found, then @code{LIBLTDL} is set to
-the link flags needed to use it, and @code{LTDLINCL} to the
-preprocessor flags needed to find the installed headers.  Note,
-however, that no version checking is performed.  You should manually
-check for the @code{libltdl} features you need in  
@file{configure.ac}:

+the link flags needed to use it, @code{LIBLTDL_DEP} is empty, and
[EMAIL PROTECTED] to the preprocessor flags needed to find the  
installed

+headers.


"If an installed @code{libltdl} is found, then @code{LIBLTDL} is set to
the link flags needed to use it, and @code{LTDLINCL} to the preprocessor
flags needed to find the installed headers, and @code{LIBLTDL_DEP} will
be empty."

I'm also not sure about the name LIBLTDL_DEP, as it is visibly different
to the other two, and also to existing PREOPEN_DEPENDENCIES and  
INFO_DEPS,
and gnulibs use of the '_DEPENDENCIES' suffix. I'd prefer either  
LTDLDEPS

(vis LTDLINCL) or LIBLTDL_DEPENDENCIES for consistency with prior art.
There are several other occurrences in the patch I haven't highlighted.


-Whatever method you use, @samp{LTDL_INIT} will define both the shell
-variable @var{LIBLTDL} to the link flag that you should use to link
-with @code{libltdl}, and the shell variable @var{LTDLINCL} to the
-preprocessor flag that you should use to compile programs that
-include @file{ltdl.h}. So, when you want to link a program with
-libltdl, be it a convenience, installed or installable library, just
-use @samp{$(LTDLINCL)} for preprocessing and compilation, and
+Whatever method you use, @samp{LTDL_INIT} will define the shell  
variable

[EMAIL PROTECTED] to the link flag that you should use to link
+with @code{libltdl}, the shell variable @var{LIBLTDL_DEP} to the file


s/file/files/


+that can be used as @command{make} dependency, and the shell variable


...can be used as a dependency in @file{Makefile} rules, ...

Actually, now that I think about it, the user doesn't see these as shell
variables at all, but as make macros.  It might be better to simply  
refer

to them as make macros to avoid any confusion.


Index: tests/configure-iface.at
===
RCS file: /cvsroot/libtool/libtool/tests/configure-iface.at,v
retrieving revision 1.5
diff -u -r1.5 configure-iface.at
--- tests/configure-iface.at12 Jan 2008 14:07:02 -  1.5
+++ tests/configure-iface.at16 Jan 2008 06:21:09 -
@@ -144,6 +145,10 @@
AT_CHECK([test -f $prefix/lib/libltdl.la])
AT_CHECK([test -f $prefix/include/ltdl.h])

+# Check that main is rebuilt if libltdl.la is newer
+rm -f libltdl/libltdl.la
+AT_CHECK([$MAKE -q main$EXEEXT || exit 1], [1], [ignore], [ignore])
+


-q might not work with some of the makes that we support.  Safer to use:

  AT_CHECK([$MAKE main$EXEEXT >/dev/null 2>&1 || exit 1], ...



@@ -262,6 +269,10 @@
## previously installed system libltdl.
LT_AT_NOINST_EXEC_CHECK([./main], [-dlopen libmodule.la], [],  
[expout], [])


+# Check that main is rebuilt if libltdlc.la is newer
+rm -f libltdl/libltdlc.la
+AT_CHECK([$MAKE -q main$EXEEXT || exit 1], [1], [ignore], [ignore])


Same here.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_  Join my AGLOCO Network:

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Bob Friesenhahn]

On Wed, 16 Jan 2008, Ralf Wildenhues wrote:



However, as usual, I don't feel qualified to review other aspects
of this patch...


Well, thanks anyway for spotting this typo!


With this change, I am ok with the documentation updates.  However, I 
am fairly confident that old libtool documentation recommended the 
opposite order, and opposite order was likely required at that time.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

When the user copies the libtool macros into aclocal.m4 (which is
discouraged but something we support), the 333 patch causes a nice
failure in a third-party package:

> [Running] /tmp/libtool/install/libtool-2.1/bin/libtoolize --automake --copy
> /tmp/libtool/install/libtool-2.1/bin/libtoolize: eval: line 991: syntax error 
> near unexpected token `[$0],'
> /tmp/libtool/install/libtool-2.1/bin/libtoolize: eval: line 991: 
> `AC_BEFORE([$0], [LTDL_INIT])dnl seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> seen_libtool=: seen_libtool=: seen_libtool=: seen_libtool=: 
> LT_OPTION_DEFINE([LTDL_INIT], [nonrecursive], LT_OPTION_DEFINE([LTDL_INIT], 
> [recursive], LT_OPTION_DEFINE([LTDL_INIT], [subproject], 
> LT_OPTION_DEFINE([LTDL_INIT], [installable], LT_OPTION_DEFINE([LTDL_INIT], 
> [convenience], auxdir=confdb seen_libtool=:'

because libtoolize wrongly recognizes code from libtool macro files,
such as
  [_LT_SET_OPTION([LT_INIT], [shared])

or
  LT_OPTION_DEFINE([LTDL_INIT], [nonrecursive],

as being user calls to setup libtool.  OK to apply this patch to fix it
and some other cases?  I realize that this is still a bit fragile when
Libtool evolves (really only m4 can parse m4), which is why I'm adding a
testcase, too.

Cheers,
Ralf

2008-01-16  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libtoolize.m4sh (func_scan_files): Avoid matching our own
macro code when scanning configure.ac and aclocal.m4.
Don't produce spurious output if AC_PROG_RANLIB is found.
* tests/old-m4-iface.at (AM_PROG_LIBTOOL): Add a (weak) check
that we don't match our own macro code when searching for user
code calling us.

Index: libtoolize.m4sh
===
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.64
diff -u -r1.64 libtoolize.m4sh
--- libtoolize.m4sh 6 Jan 2008 16:33:30 -   1.64
+++ libtoolize.m4sh 16 Jan 2008 19:28:21 -
@@ -418,14 +418,18 @@
s,^.*LT_CONFIG_LTDL_DIR([[   ]*\([^])]*\).*$,ac_ltdldir=\1,
p
}
+   /\@<:@A[CM]_PROG_LIBTOOL/d
/A[CM]_PROG_LIBTOOL/ {
s,^.*$,seen_libtool=:,
p
}
+   /the.*option into.*LT_INIT.*parameter/d
+   /\@<:@LT_INIT/d
/LT_INIT/{
s,^.*$,seen_libtool=:,
p
}
+   /\@<:@LTDL_INIT/d
/LTDL_INIT/  {
s,^.*LTDL_INIT([[   ]*\([^])]*\).*$,ltdl_options="\1",
s,^.*LTDL_INIT[ ]*$,seen_ltdl=:,
@@ -960,7 +964,7 @@
 else
   # Don't trace for this, we're just checking the user didn't invoke it
   # directly from configure.ac.
-  $SED 's,dnl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB &&
+  $SED 's,dnl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB 
>/dev/null &&
 func_echo "\`AC_PROG_RANLIB' is rendered obsolete by \`LT_INIT'"
 fi
 
Index: tests/old-m4-iface.at
===
RCS file: /cvsroot/libtool/libtool/tests/old-m4-iface.at,v
retrieving revision 1.14
diff -u -r1.14 old-m4-iface.at
--- tests/old-m4-iface.at   12 Jan 2008 14:07:02 -  1.14
+++ tests/old-m4-iface.at   16 Jan 2008 19:34:28 -
@@ -86,6 +86,17 @@
 
 LT_AT_EXEC_CHECK([./old], 0, [Hello, World!])
 
+# Now, test that libtoolize doesn't mistakenly think the user called
+# any libtool macros if in fact she didn't.
+sed '/AM_PROG_LIBTOOL/d' configure.in >configure.int
+mv -f configure.int configure.in
+AT_CHECK([$LIBTOOLIZE -n], [0], [stdout], [stderr])
+# ensure no shell errors:
+AT_CHECK([grep -v "^libtoolize: " stderr], [1])
+AT_CHECK([grep "Remember to add.*LT_INIT.*to configure.in" stdout], [0], 
[ignore])
+AT_CHECK([grep "Consider adding.*LT_WITH_LTDL" stdout], [1])
+AT_CHECK([grep "Remember to add.*LT_CONFIG_LTDL_DIR" stdout], [1])
+
 AT_CLEANUP
 
 

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Wed, Jan 16, 2008 at 08:13:59PM CET:
> On Wed, Jan 16, 2008 at 08:07:41PM +0100, Ralf Wildenhues wrote:
> 
> > [EMAIL PROTECTED] macro (after the call to @samp{LTDL_INIT}
> 
> Is the second instance a typo? Should be LT_INIT, right?

Yes.

> However, as usual, I don't feel qualified to review other aspects
> of this patch...

Well, thanks anyway for spotting this typo!

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Peter Rosin]

On Wed, Jan 16, 2008 at 08:07:41PM +0100, Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Sat, Jan 12, 2008 at 03:15:03PM CET:
> > 
> > So I ask to please clarify once and for all the order in which things
> > should be (including a notice in NEWS), the rationale for it, and please
> > to make it clear in the manual whether LTDL_INIT requires that LT_INIT
> > also be called or not (some examples given in the manual carry LTDL_INIT
> > but do not mention LT_INIT at all).
> 
> OK to apply this fix?

[snip]

> [EMAIL PROTECTED] macro (after the call to @samp{LTDL_INIT}

Is the second instance a typo? Should be LT_INIT, right?

However, as usual, I don't feel qualified to review other aspects
of this patch...

Cheers,
Peter

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sat, Jan 12, 2008 at 03:15:03PM CET:
> 
> So I ask to please clarify once and for all the order in which things
> should be (including a notice in NEWS), the rationale for it, and please
> to make it clear in the manual whether LTDL_INIT requires that LT_INIT
> also be called or not (some examples given in the manual carry LTDL_INIT
> but do not mention LT_INIT at all).

OK to apply this fix?

Cheers,
Ralf

2008-01-16  Ralf Wildenhues  <[EMAIL PROTECTED]>

* doc/libtool.texi (Distributing libltdl): Clarify that
LTDL_INIT goes after LT_INIT; also show the latter in the
respective examples.
* tests/subproject.at: Adjust order.

Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.234
diff -u -r1.234 libtool.texi
--- doc/libtool.texi6 Jan 2008 16:33:30 -   1.234
+++ doc/libtool.texi16 Jan 2008 19:07:07 -
@@ -4378,7 +4378,8 @@
 if you move to a different release of libltdl.
 @c
 }.  Having made the macros available, you must add a call to the
[EMAIL PROTECTED] macro to your package's @file{configure.ac} to
[EMAIL PROTECTED] macro (after the call to @samp{LTDL_INIT}
+to your package's @file{configure.ac} to
 perform the configure time checks required to build the library
 correctly.  Unfortunately, this method has problems if you then try to
 link the package binaries with an installed libltdl, or a library that
@@ -4489,6 +4490,7 @@
 AM_INIT_AUTOMAKE([subdir-objects])
 AC_CONFIG_HEADERS([config.h])
 LT_CONFIG_LTDL_DIR([libltdl])
+LT_INIT([dlopen])
 LTDL_INIT([nonrecursive])
 @end example
 
@@ -4531,6 +4533,7 @@
 AM_INIT_AUTOMAKE
 AC_CONFIG_HEADERS([config.h])
 LT_CONFIG_LTDL_DIR([libltdl])
+LT_INIT([dlopen])
 LTDL_INIT([recursive])
 AC_CONFIG_FILES([libltdl/Makefile])
 @end example
Index: tests/subproject.at
===
RCS file: /cvsroot/libtool/libtool/tests/subproject.at,v
retrieving revision 1.13
diff -u -r1.13 subproject.at
--- tests/subproject.at 8 Jan 2008 05:07:41 -   1.13
+++ tests/subproject.at 16 Jan 2008 19:07:07 -
@@ -33,8 +33,8 @@
 AC_CONFIG_AUX_DIR([sub/ltdl/config])
 AC_CONFIG_MACRO_DIR([sub/ltdl/m4])
 AM_INIT_AUTOMAKE([foreign])
-LT_WITH_LTDL
 LT_INIT
+LT_WITH_LTDL
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 ]])

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Jan 08, 2008 at 08:34:05AM CET:
> * Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
> > >
> > >Sure you want to disallow users just passing in appropriate CPPFLAGS  
> > >and
> > >LDFLAGS to find an installed libltdl?  I would count that as an
> > >incompatible API change, too.
> > 
> > CPPFLAGS and LDFLAGS will continue to work as they always have done.  It
> > seems far too obvious to mention in the docs though.  I have noticed  
> > that many autotools users seem to prefer passing --enable/with-options
> > though so I'm providing those too.
> 
> Oh, I thought they wouldn't work.  Guess I should have tested that.

Nevermind.  The testsuite shows that they work.

> > >This fails to mention whether $(LIBLTDL) may be used as a dependency  
> > >in,
> > >say, libfoo_la_DEPENDENCIES.  The case where it is `-lltdl' is the
> > >tricky one, as it leads to a make error, so we may have to introduce
> > >another variable?  See M4 build failures on Bob's build farm for an
> > >example of this.
> > 
> > Hmm.  Bummer.  Could you add a test?  Or, Bob, if you could give me
> > access to your build logs, I'll look into creating one myself.
> 
> Sorry about the confusion.  I meant Bob Proulx, and these buildds:
> 
> Seems the M4 one is off-line ATM.

Below's a patch for that issue.

> > >These two paragraphs are factually wrong if top_build_prefix is
> > >available (i.e., with new enough Autoconf).
> > 
> > Oh.  Guess I haven't been paying attention to the Autoconf developments
> > for a while then :-(  What should I have written instead?
> 
> Well if $top_build_prefix is available, then that will be the start of
> the path names for LIBLTDL, instead of $top_builddir/
> The difference is that, in case $top_builddir is `.', $top_build_prefix
> is empty, which helps non-GNU make as they see `FILE' not `./FILE'
> (which isn't the same for them).

Also dealt with in the patch below.

OK to apply?

Cheers,
Ralf

2008-01-16  Ralf Wildenhues  <[EMAIL PROTECTED]>

New variable LIBLTDL_DEP for use in output_DEPENDENCIES.
* libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE, _LTDL_INSTALLABLE)
(LTDL_INIT): Set and substitute LIBLTDL_DEP according to chosen
method.
* tests/configure-iface.at (installable libltdl)
(--with-ltdl-include/lib, --with-included-ltdl): Test it.
* doc/libtool.texi (Distributing libltdl): Document LIBLTDL_DEP.
Also clarify that `${top_build_prefix}' may be used in place of
`${top_builddir}/'.
* NEWS: Update.
Dependency bug exposed by Eric Blake in M4, found by Bob Proulx
build daemon.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.214
diff -u -r1.214 NEWS
--- NEWS12 Jan 2008 17:00:51 -  1.214
+++ NEWS16 Jan 2008 06:21:03 -
@@ -52,6 +52,7 @@
 The Libtool package itself builds libltdl nonrecursively.
   - The 'nonrecursive', 'recursive' and 'subproject' libltdl build
 modes are given as LTDL_INIT options.
+  - New make variable LIBLTDL_DEP for use in output_DEPENDENCIES.
   - New multi-module-loader safe libltdl handle iteration APIs:
 lt_dlhandle_iterate, lt_dlhandle_fetch, lt_dlhandle_map.
   - New lt_dlinterface_register to maintain separation of concerns
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.234
diff -u -r1.234 libtool.texi
--- doc/libtool.texi6 Jan 2008 16:33:30 -   1.234
+++ doc/libtool.texi16 Jan 2008 06:21:06 -
@@ -4443,10 +4443,11 @@
 @option{--with-included-ltdl}.
 
 If an installed @code{libltdl} is found, then @code{LIBLTDL} is set to
-the link flags needed to use it, and @code{LTDLINCL} to the
-preprocessor flags needed to find the installed headers.  Note,
-however, that no version checking is performed.  You should manually
-check for the @code{libltdl} features you need in @file{configure.ac}:
+the link flags needed to use it, @code{LIBLTDL_DEP} is empty, and
[EMAIL PROTECTED] to the preprocessor flags needed to find the installed
+headers.  Note, however, that no version checking is performed.  You
+should manually check for the @code{libltdl} features you need in
[EMAIL PROTECTED]:
 
 @example
 LT_INIT([dlopen])
@@ -4585,7 +4586,7 @@
 to cause it to be built as a convenience library.  If you're not
 using automake, you will need to define @code{top_build_prefix},
 @code{top_builddir}, and @code{top_srcdir} in your makefile so that
[EMAIL PROTECTED] and @code{LTDLINCL} expand correctly.
[EMAIL PROTECTED], @code{LIBLTDL_DEP}, and @code{LTDLINCL} expand correctly.
 
 One advantage of the convenience library is that it is not installed,
 so the fact that you use @code{libltdl} will not be apparent to the
@@ -4609,42 +4610,46 @@
 to cause it to be 

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

On 15 Jan 2008, at 15:23, Ralf Wildenhues wrote:

* Gary V. Vaughan wrote on Tue, Jan 15, 2008 at 08:04:35AM CET:

On 15 Jan 2008, at 14:24, Ralf Wildenhues wrote:


Expect a fix for the remaining fallout from 333 soon.


I thought this was the last thing?


No.


What else needs to be addressed before I can roll an alpha (excepting
Peter's current work)?


These have not been fully addressed:



But I had a half-working patch last night.



Thanks for the reminder.  If you have something in the pipeline, then I
won't duplicate what you've done.  On the other hand if there is  
something

I can help with, just let me know.

Once I see these have been addressed, I'll roll 2.1b right away.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_  Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Tue, Jan 15, 2008 at 08:04:35AM CET:
> On 15 Jan 2008, at 14:24, Ralf Wildenhues wrote:
>>
>> Expect a fix for the remaining fallout from 333 soon.
>
> I thought this was the last thing?

No.

> What else needs to be addressed before I can roll an alpha (excepting  
> Peter's current work)?

These have not been fully addressed:


But I had a half-working patch last night.

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

On 15 Jan 2008, at 14:24, Ralf Wildenhues wrote:


Expect a fix for the remaining fallout from 333 soon.


I thought this was the last thing?

What else needs to be addressed before I can roll an alpha (excepting  
Peter's

current work)?

Cheers,
Gary
--
Gary V. Vaughan ([EMAIL PROTECTED])





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Jan 15, 2008 at 03:22:07AM CET:
> On 15 Jan 2008, at 03:24, Ralf Wildenhues wrote:
> >OK to apply this fix (feeling a bit hackish, but does exactly what's
> >needed)?
> 
> Absolutely.  Sorry I didn't get to it sooner myself.  I can't think of a
> cleaner way to tackle it myself off the top of my head, please go ahead
> and commit.

Thanks, done.  Expect a fix for the remaining fallout from 333 soon.

Cheers,
Ralf

> > * configure.ac: Set libltdl nonrecursive option, to avoid
> > configuring libltdl inside the Libtool package.

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Tag Ralf,

On 15 Jan 2008, at 03:24, Ralf Wildenhues wrote:


* Ralf Wildenhues wrote on Tue, Jan 08, 2008 at 08:29:05PM CET:

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:

On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:


With this patch, I see in the log of
make distcheck

that the libltdl subdirectory is being configured.  This is  
wrong, as
libltdl in the Libtool package should be in nonrecursive mode  
rather
than in subproject mode.  This causes distcheck to fail.  Can you  
fix

this?


I noticed this yesterday when I started the alpha release process  
too.

Yes, I'll figure this out before I go any further.


It is because _LTDL_SETUP calls _LTDL_MODE_DISPATCH which calls
AC_CONFIG_SUBDIRS.  That's wrong, no?  Is that because implicitly
subproject-libltdl mode is assumed for the Libtool package?


OK to apply this fix (feeling a bit hackish, but does exactly what's
needed)?


Absolutely.  Sorry I didn't get to it sooner myself.  I can't think of a
cleaner way to tackle it myself off the top of my head, please go ahead
and commit.


2008-01-14  Ralf Wildenhues  <[EMAIL PROTECTED]>

* configure.ac: Set libltdl nonrecursive option, to avoid
configuring libltdl inside the Libtool package.


Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_  Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hello Gary,

I've applied this patch to fix an omission in your change.

Cheers,
Ralf

2008-01-14  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libltdl/m4/ltoptions.m4 (AC_ENABLE_SHARED): Fix to use
new _LT_SET_OPTION semantics.

Index: libltdl/m4/ltoptions.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltoptions.m4,v
retrieving revision 1.10
diff -u -r1.10 ltoptions.m4
--- libltdl/m4/ltoptions.m4 6 Jan 2008 16:33:31 -   1.10
+++ libltdl/m4/ltoptions.m4 14 Jan 2008 21:18:06 -
@@ -188,7 +188,7 @@
 
 # Old names:
 AC_DEFUN([AC_ENABLE_SHARED],
-[_LT_SET_OPTION([shared])
+[_LT_SET_OPTION([LT_INIT], [shared])
 ])
 
 AC_DEFUN([AC_DISABLE_SHARED],

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Jan 08, 2008 at 08:29:05PM CET:
> * Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
> > On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:
> >
> >> With this patch, I see in the log of
> >>  make distcheck
> >>
> >> that the libltdl subdirectory is being configured.  This is wrong, as
> >> libltdl in the Libtool package should be in nonrecursive mode rather
> >> than in subproject mode.  This causes distcheck to fail.  Can you fix
> >> this?
> >
> > I noticed this yesterday when I started the alpha release process too.
> > Yes, I'll figure this out before I go any further.
> 
> It is because _LTDL_SETUP calls _LTDL_MODE_DISPATCH which calls
> AC_CONFIG_SUBDIRS.  That's wrong, no?  Is that because implicitly
> subproject-libltdl mode is assumed for the Libtool package?

OK to apply this fix (feeling a bit hackish, but does exactly what's
needed)?

Cheers,
Ralf

2008-01-14  Ralf Wildenhues  <[EMAIL PROTECTED]>

* configure.ac: Set libltdl nonrecursive option, to avoid
configuring libltdl inside the Libtool package.

Index: configure.ac
===
RCS file: /cvsroot/libtool/libtool/configure.ac,v
retrieving revision 1.79
diff -u -r1.79 configure.ac
--- configure.ac6 Jan 2008 16:33:30 -   1.79
+++ configure.ac14 Jan 2008 19:24:05 -
@@ -181,6 +181,7 @@
 ## Libtool initialisation. ##
 ## --- ##
 LT_INIT([dlopen win32-dll])
+_LT_SET_OPTION([LTDL_INIT], [nonrecursive])
 _LTDL_SETUP
 
 # Enable all the language support we can

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
[...]
>>>  Index: ChangeLog
>>>  from  Gary V. Vaughan  <[EMAIL PROTECTED]>
[...]
>>> * libltdl/m4/libtool.m4 (LT_INIT): Declare that this macro must be
>>> expanded before LTDL_INIT, and be sure to parse caller options.

This is contrary to what I think we recommended in earlier 1.9X times
(but I may be misremembering), it is contrary to the code in
subproject.at (plain oversight?), and it is for example done the other
way round in GraphicsMagick, but OTOH not in
branch-1-5/libltdl/configure.ac.

So I ask to please clarify once and for all the order in which things
should be (including a notice in NEWS), the rationale for it, and please
to make it clear in the manual whether LTDL_INIT requires that LT_INIT
also be called or not (some examples given in the manual carry LTDL_INIT
but do not mention LT_INIT at all).

I have some pending patch for which I need to know the order.

Thank you,
Ralf

Index: tests/subproject.at
===
RCS file: /cvsroot/libtool/libtool/tests/subproject.at,v
retrieving revision 1.13
diff -u -r1.13 subproject.at
--- tests/subproject.at 8 Jan 2008 05:07:41 -   1.13
+++ tests/subproject.at 12 Jan 2008 14:14:48 -
@@ -33,8 +33,8 @@
 AC_CONFIG_AUX_DIR([sub/ltdl/config])
 AC_CONFIG_MACRO_DIR([sub/ltdl/m4])
 AM_INIT_AUTOMAKE([foreign])
-LT_WITH_LTDL
 LT_INIT
+LT_WITH_LTDL
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 ]])

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 10:00:30AM CET:
> On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:
>
>> There is code that checks $prefix/lib.  I realize this has been that  
>> way
>> before your patch, but shouldn't we test (expanded) $libdir instead,  
>> so
>> that users of libdir='${prefix}/lib64' get what they want?
>
>
> Hmm.  Well, looking through the expanded testsuite, and the Makefile  
> rules that call it, libdir is not set.  Some of our tests fake it by
> setting  it in the .at file (link-order.at f'rinstance), but that
> won't help a user with libraries in lib64.
>
> I think I'm not understanding what you're asking for here.  Unless it is
> fixing a bug, then I'd like to leave it until after the release.

We can well leave it until after the release.

What I meant is this: libdir is usually initialized near the beginning
of a configure script (by Autoconf boilerplate code) like this:
  libdir='${prefix}/lib'

and it can be overridden by the user, e.g.:
  ./configure --prefix=/foo --libdir=/foo/lib64

in which case we'd be looking at /foo/lib.  But that's not all that
important, users can always get what they want by specifying LIBLTDL
correctly.

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
> On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:
>
>> With this patch, I see in the log of
>>  make distcheck
>>
>> that the libltdl subdirectory is being configured.  This is wrong, as
>> libltdl in the Libtool package should be in nonrecursive mode rather
>> than in subproject mode.  This causes distcheck to fail.  Can you fix
>> this?
>
> I noticed this yesterday when I started the alpha release process too.
> Yes, I'll figure this out before I go any further.

It is because _LTDL_SETUP calls _LTDL_MODE_DISPATCH which calls
AC_CONFIG_SUBDIRS.  That's wrong, no?  Is that because implicitly
subproject-libltdl mode is assumed for the Libtool package?

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

Hallo Ralf,

On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:

There is code that checks $prefix/lib.  I realize this has been that  
way
before your patch, but shouldn't we test (expanded) $libdir instead,  
so

that users of libdir='${prefix}/lib64' get what they want?



Hmm.  Well, looking through the expanded testsuite, and the Makefile  
rules
that call it, libdir is not set.  Some of our tests fake it by setting  
it

in the .at file (link-order.at f'rinstance), but that won't help a user
with libraries in lib64.

I think I'm not understanding what you're asking for here.  Unless it is
fixing a bug, then I'd like to leave it until after the release.

Cheers,
Gary
--
Gary V. Vaughan ([EMAIL PROTECTED])





PGP.sig
Description: This is a digitally signed message part

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hello Gary, Bob, Bob,

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
> >
> >Sure you want to disallow users just passing in appropriate CPPFLAGS  
> >and
> >LDFLAGS to find an installed libltdl?  I would count that as an
> >incompatible API change, too.
> 
> CPPFLAGS and LDFLAGS will continue to work as they always have done.  It
> seems far too obvious to mention in the docs though.  I have noticed  
> that many autotools users seem to prefer passing --enable/with-options
> though so I'm providing those too.

Oh, I thought they wouldn't work.  Guess I should have tested that.

> >
> >This fails to mention whether $(LIBLTDL) may be used as a dependency  
> >in,
> >say, libfoo_la_DEPENDENCIES.  The case where it is `-lltdl' is the
> >tricky one, as it leads to a make error, so we may have to introduce
> >another variable?  See M4 build failures on Bob's build farm for an
> >example of this.
> 
> Hmm.  Bummer.  Could you add a test?  Or, Bob, if you could give me
> access to your build logs, I'll look into creating one myself.

Sorry about the confusion.  I meant Bob Proulx, and these buildds:

Seems the M4 one is off-line ATM.

> >> [EMAIL PROTECTED]
> >> +If your package is built using the convenience libltdl,  
> >>@var{LIBLTDL}
> >> +will be the pathname for the convenience version of libltdl
> >> +(starting with @[EMAIL PROTECTED]@}/}) and @var{LTDLINCL} will  
> >>be
> >> [EMAIL PROTECTED] followed by the directory that contains @file{ltdl.h}
> >> +(starting with @[EMAIL PROTECTED]@}/}).
> >> +
> >> [EMAIL PROTECTED]
> >> +If an installable version of the included @code{libltdl} is being
> >> +built, its pathname starting with @[EMAIL PROTECTED]@}/}, will  
> >>be
> >> +stored in @var{LIBLTDL}, and @var{LTDLINCL} will be set just like  
> >>in
> >> +the case of convenience library.
> >> [EMAIL PROTECTED] itemize
> >
> >These two paragraphs are factually wrong if top_build_prefix is
> >available (i.e., with new enough Autoconf).
> 
> Oh.  Guess I haven't been paying attention to the Autoconf developments
> for a while then :-(  What should I have written instead?

Well if $top_build_prefix is available, then that will be the start of
the path names for LIBLTDL, instead of $top_builddir/
The difference is that, in case $top_builddir is `.', $top_build_prefix
is empty, which helps non-GNU make as they see `FILE' not `./FILE'
(which isn't the same for them).

This fix is quite new, the Libtool patch is the one right before your
big one.

> >> @@ -617,10 +620,10 @@
> >>lt_cl_silent=: ;;
> >>
> >>  -*) AC_MSG_ERROR([unrecognized option: $[1]
> >> -Try `$[0] --help' for more information.]) ;;
> >> +Try \`$[0] --help' for more information.]) ;;
> >>
> >>  *) AC_MSG_ERROR([unrecognized argument: $[1]
> >> -Try `$[0] --help for more information.]) ;;
> >> +Try \`$[0] --help' for more information.]) ;;
> >
> >This hunk is completely superfluous.  Backticks get escaped properly
> >automatically with AC_MSG_ERROR.
> 
> Even with old autoconf?

Do we support anything older than 2.58 in practice?

> >> --- /dev/null  1 Jan 1970 00:00:00 -
> >> +++ tests/configure-iface.at 6 Jan 2008 16:32:11 -
> >
> >> +# TODO: Check that the installed program `main' is linked against  
> >>our libltdl
> >> +AT_CHECK([test -f $prefix/lib/libltdl.la])
> >> +AT_CHECK([test -f $prefix/include/ltdl.h])
> >
> >Yep, that TODO is a rather important test that is missing.  It will be
> >crucial on systems like OpenBSD.
> 
> I'm not sure how to test it though... any thoughts?

As below: build and install a fake libltdl, require failure to link.

> >> +# Remove build files
> >> +for x in .* *; do
> >> +  test $x == _inst || rm -rf $x
> >> +done
> >
> >That doesn't work.  Apart from the quoting errors ("$x"),
> 
> From the line above $x can never be empty (at worst it will be a  
> literal
> '*').

It could contain spaces though.  Yes, highly unlikely.

Cheers,
Ralf

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Gary V. Vaughan]

On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:

Hello Gary,


Morgen Ralf,

Thanks for the review.


* Gary V. Vaughan wrote on Sun, Jan 06, 2008 at 05:35:30PM CET:


I'm going to try and roll an alpha release for wider testing over the
next day or two.


Well, I finally got done with my look over this, so you may want to
consider it first.  And when you're done and bored again, I will  
post a

few test failures to ponder over, ok?  ;-)


I'll address whatever I can before I roll up the alpha and have my INBOX
flooded :-)

Why is the same name, _LTDL_SETUP, used for an internal macro in  
ltdl.m4

as well as for a helper macro in tests/*at?


Just bad memory.  Actually, the at macro is pushed and popped so  
everything
continues to work properly, even so I'll fix it to avoid confusion  
later.



Moreover, why is the
internal macro leaking into configure.ac and libltdl/configure.ac?
(Hmm, upon rereading, maybe that last item is just the way it has
to be; sigh.)


I think it is okay to use libtool internal macros internally to  
libtool ;-)

It's not as pretty as I'd like, but if we think of a better way later we
can always change it.  For now I just want to make the release already!


With this patch, I see in the log of
 make distcheck

that the libltdl subdirectory is being configured.  This is wrong, as
libltdl in the Libtool package should be in nonrecursive mode rather
than in subproject mode.  This causes distcheck to fail.  Can you fix
this?


I noticed this yesterday when I started the alpha release process too.
Yes, I'll figure this out before I go any further.

There is code that checks $prefix/lib.  I realize this has been that  
way
before your patch, but shouldn't we test (expanded) $libdir instead,  
so

that users of libdir='${prefix}/lib64' get what they want?


Nice catch!  I'll patch that separately in a moment.  Thanks.




 Index: ChangeLog
 from  Gary V. Vaughan  <[EMAIL PROTECTED]>

Move libltdl build mode options from LT_CONFIG_LTDL_DIR to
LTDL_INIT.  Accept (optional) new 'convenience' and 'installable'
options in lieu of LTDL_CONVENIENCE and LTDL_INSTALL macros. And
also, implement --with-included-ltdl, --with-ltdl-lib and
--with-ltdl-include configure-time options:

* libltdl/m4/ltoptions.m4: Associate existing option settings with
LT_INIT.
(LT_OPTION_DEFINE): Associate options 'nonrecursive', 'recursive',
'subproject', 'installable' and 'convenience' with LTDL_INIT.
(_LT_MANGLE_OPTION, _LT_SET_OPTION, _LT_IF_OPTION)
(_LT_UNLESS_OPTIONS, _LT_SET_OPTIONS): Add MACRO-NAME argument to
support options to named macros instead of hardcoding only LT_INIT
options.
* libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE): Factor common code from
LTDL_CONVENIENCE and LTDL_INIT([convenience]).
(_LTDL_INSTALLABLE): Factor out common code from LTDL_INSTALLABLE
and LTDL_INIT([installable]).
(_LTDL_SETUP): Renamed from LTDL_INIT.  Support new configure-time
options: --with-included-ltdl, --with-ltdl-lib,
--with-ltdl-include.
(LTDL_CONVENIENCE, LTDL_INSTALLABLE): Adjust.
(LT_WITH_LTDL): Removed.
(LTDL_INIT): Parse caller options.
* libltdl/m4/libtool.m4 (LT_INIT): Declare that this macro must be
expanded before LTDL_INIT, and be sure to parse caller options.
* configure.ac: Call directly into internal _LTDL_SETUP macro.
* libtoolize.m4sh (func_scan_files): Ltdl mode argument moved from
LT_CONFIG_LTDL_DIR to LT_INIT.


s/LT_INIT/LTDL_INIT/  ?


ACK.


* tests/nonrecursive.at, tests/recursive.at: Use new interfaces.
* tests/configure-iface.at: Test it.
* Makefile.am (TESTSUITE_AT): Add configure-iface.at.
* doc/libtool.texi (Distributing libltdl): Document improved.


s/\.$//  ?


D'oh!  ACK.


 Index: NEWS
 ===
 RCS file: /sources/libtool/libtool/NEWS,v
 retrieving revision 1.209
 diff -u -u -r1.209 NEWS
 --- NEWS 2 Jan 2008 18:52:08 - 1.209
 +++ NEWS 6 Jan 2008 16:32:05 -

[...]

 @@ -31,6 +33,14 @@
- Fix installation of libltdl so that it does not need Autoconf  
and
  Automake installed, in order to be usable in another  
package.  This

  lifts the restrictions introduced in 1.9b.
 +  - Default convenience or installable libltdl builds can  
optionally

 +be declared using new `convenience' or `installable' options to


s/$/ the/


ACK.


 Index: libtoolize.m4sh
 ===
 RCS file: /sources/libtool/libtool/libtoolize.m4sh,v
 retrieving revision 1.63
 diff -u -u -r1.63 libtoolize.m4sh
 --- libtoolize.m4sh 2 Jan 2008 18:52:08 - 1.63
 +++ libtoolize.m4sh 6 Jan 2008 16:32:07 -



 @@ -481,9 +480,26 @@
  # Validate ltdl_mode. #
  # --- #

 -test -n "$ac_ltdl_mode" && seen_ltdl=:

Re: FYI: 333-gary-refactor-LTDL_INIT.patch

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Sun, Jan 06, 2008 at 05:35:30PM CET:
> 
> I'm going to try and roll an alpha release for wider testing over the
> next day or two.

Well, I finally got done with my look over this, so you may want to
consider it first.  And when you're done and bored again, I will post a
few test failures to ponder over, ok?  ;-)


Why is the same name, _LTDL_SETUP, used for an internal macro in ltdl.m4
as well as for a helper macro in tests/*at?  Moreover, why is the
internal macro leaking into configure.ac and libltdl/configure.ac?
(Hmm, upon rereading, maybe that last item is just the way it has 
to be; sigh.)

With this patch, I see in the log of
  make distcheck

that the libltdl subdirectory is being configured.  This is wrong, as
libltdl in the Libtool package should be in nonrecursive mode rather
than in subproject mode.  This causes distcheck to fail.  Can you fix
this?

There is code that checks $prefix/lib.  I realize this has been that way
before your patch, but shouldn't we test (expanded) $libdir instead, so
that users of libdir='${prefix}/lib64' get what they want?

>   Index: ChangeLog
>   from  Gary V. Vaughan  <[EMAIL PROTECTED]>
>   
>   Move libltdl build mode options from LT_CONFIG_LTDL_DIR to
>   LTDL_INIT.  Accept (optional) new 'convenience' and 'installable'
>   options in lieu of LTDL_CONVENIENCE and LTDL_INSTALL macros. And
>   also, implement --with-included-ltdl, --with-ltdl-lib and
>   --with-ltdl-include configure-time options:
>   
>   * libltdl/m4/ltoptions.m4: Associate existing option settings with
>   LT_INIT.
>   (LT_OPTION_DEFINE): Associate options 'nonrecursive', 'recursive',
>   'subproject', 'installable' and 'convenience' with LTDL_INIT.
>   (_LT_MANGLE_OPTION, _LT_SET_OPTION, _LT_IF_OPTION)
>   (_LT_UNLESS_OPTIONS, _LT_SET_OPTIONS): Add MACRO-NAME argument to
>   support options to named macros instead of hardcoding only LT_INIT
>   options.
>   * libltdl/m4/ltdl.m4 (_LTDL_CONVENIENCE): Factor common code from
>   LTDL_CONVENIENCE and LTDL_INIT([convenience]).
>   (_LTDL_INSTALLABLE): Factor out common code from LTDL_INSTALLABLE
>   and LTDL_INIT([installable]).
>   (_LTDL_SETUP): Renamed from LTDL_INIT.  Support new configure-time
>   options: --with-included-ltdl, --with-ltdl-lib,
>   --with-ltdl-include.
>   (LTDL_CONVENIENCE, LTDL_INSTALLABLE): Adjust.
>   (LT_WITH_LTDL): Removed.
>   (LTDL_INIT): Parse caller options.
>   * libltdl/m4/libtool.m4 (LT_INIT): Declare that this macro must be
>   expanded before LTDL_INIT, and be sure to parse caller options.
>   * configure.ac: Call directly into internal _LTDL_SETUP macro.
>   * libtoolize.m4sh (func_scan_files): Ltdl mode argument moved from
>   LT_CONFIG_LTDL_DIR to LT_INIT.

s/LT_INIT/LTDL_INIT/  ?

>   * tests/nonrecursive.at, tests/recursive.at: Use new interfaces.
>   * tests/configure-iface.at: Test it.
>   * Makefile.am (TESTSUITE_AT): Add configure-iface.at.
>   * doc/libtool.texi (Distributing libltdl): Document improved.

s/\.$//  ?

>   LTDL_INIT interfaces.
>   * NEWS: Updated.
>   

>   Index: NEWS
>   ===
>   RCS file: /sources/libtool/libtool/NEWS,v
>   retrieving revision 1.209
>   diff -u -u -r1.209 NEWS
>   --- NEWS 2 Jan 2008 18:52:08 - 1.209
>   +++ NEWS 6 Jan 2008 16:32:05 -
[...]
>   @@ -31,6 +33,14 @@
>  - Fix installation of libltdl so that it does not need Autoconf and
>Automake installed, in order to be usable in another package.  This
>lifts the restrictions introduced in 1.9b.
>   +  - Default convenience or installable libltdl builds can optionally
>   +be declared using new `convenience' or `installable' options to

s/$/ the/

>   +LTDL_INIT macro (as an alternative to individual LTDL_CONVENIENCE
>   +or LTDL_INSTALLABLE invocations).
>   +  - New configure-time options to allow libltdl parent project builder
>   +to choose between installed and shipped libltdl, when invoking
>   +LTDL_INIT: --with-included-ltdl, --with-ltdl-include,
>   +--with-ltdl-lib.
>  - New LT_CONFIG_LTDL_DIR macro to specify a different directory name
>for a convenience libltdl.
>  - libtoolize has been completely overhauled.

>   Index: libtoolize.m4sh
>   ===
>   RCS file: /sources/libtool/libtool/libtoolize.m4sh,v
>   retrieving revision 1.63
>   diff -u -u -r1.63 libtoolize.m4sh
>   --- libtoolize.m4sh 2 Jan 2008 18:52:08 - 1.63
>   +++ libtoolize.m4sh 6 Jan 2008 16:32:07 -

>   @@ -481,9 +480,26 @@
># Validate ltdl_mode. #
># --- #
>
>   -test -n "$ac_ltdl_mode" && seen_ltdl=:
>   +test -n "$ltdl_options" && seen_ltdl=:
>
>   -# If neither --ltdl nor LT_CONFIG_LTDL_DIR are specified, default to