Re: FYI: test subproject ltdl [283]
Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 05, 2005 at 06:19:05PM CEST: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Wed, Oct 05, 2005 at 05:04:34PM CEST: > > > >>Applied to HEAD. > > > >Doesn't work, unfortunately. > Gah! Pesky CVS... why can't it tell when I add a new file like arch? *snip* > As soon as libtool-2.0 is done, I need to write a 'quilt flush' that > automates this in much the same way as my tlaapply script, but with the > advantage of being able to run any cvs add/remove's before committing, > posting and synching... That would surely help. Bugs in there could cause havoc, though. > >But quoting some suspicious lines: > > Actually, they make a lot more sense as long as they are applied after > 287-gary-implicit-libtoolize-ltdl.diff (not yet posted for review, as > I'm still testing). Make sure to test it on a large complicated package (where some subprojects use libltdl, some don't), otherwise I'm going to be pretty "new feature, not bugfix, so post-2.0"-minded. > I'll cvs commit the right version of subproject.at as soon as the testsuite > finishes its current run. Sorry about that. Thanks, the updated version seems to work fine. Cheers, Ralf
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
Hi Nicolas,
To the Fortran part of your answer:
* Nicolas Joly wrote on Wed, Oct 05, 2005 at 03:22:10PM CEST:
> On Wed, Oct 05, 2005 at 10:43:40AM +0200, Ralf Wildenhues wrote:
>
> > Could you also try the new test suite?
> > make check TESTS=
> > and send tests/testsuite.log for errors.
>
> Got 3 failures; log attached.
The first one I can't explain yet (Gary?), the other two are easy:
libtool doesn't support Fortran on Tru64 yet. I'm actually surprised
there aren't more failures, both Fortran-related in the old testsuite,
and non-Fortran related in the new one. :)
For the rest of this mail, I assume this link has suitable(?)
documentation for these Fortran compilers:
http://h21007.www2.hp.com/dspp/files/unprotected/Fortran/docs/unix-um/dfumtoc.htm
data points:
- the doc mentions that undefined symbols are not allowed -- but ld(1)
says otherwise. Maybe it works with
allow_undefined_flag="\${wl}-expect_unresolved \${wl}\*"
or, if it doesn't, we need to set
allow_undefined_flag=unsupported
- all of `-soname ..', `-msym', `-set_version ..', `-update_registry ..'
seem unsupported by f77/f95, but I believe they should be supplied to
ld by prefixing ${wl} everywhere -- not really sure, though.
This suggests that it should be possible to write archive_cmds (and
possibly archive_expsyms_cmds) in libltdl/m4/libtool.m4:_LT_LINKER_SHLIBS
like a mixture of the $GCC and the non-$GCC case, using $cc_basename and
$GCC as decision criteria. Would you be willing to work on this?
Should I create a preliminary patch you could test? Is there also a
`f90' available on this platform?
> uname -m = alpha
> uname -r = V5.1
> uname -s = OSF1
> uname -v = 2650
> Failed tests:
> libtool 2.1a test suite test groups:
>
> NUM: FILE-NAME:LINE TEST-GROUP-NAME
> KEYWORDS
>
>4: libtoolize.at:287 copy ltdl.m4 with shared macro directory
>9: convenience.at:74 F77 convenience archives
> F77
> 10: convenience.at:116 FC convenience archives
> FC
> # -*- compilation -*-
> 9. convenience.at:74: testing ...
> ./convenience.at:75: test -n "$F77" || (exit 77)
> libtool: link: creating libb.la
> libtool: link: ( cd ".libs" && rm -f "libb.la" && ln -s "../libb.la"
> "libb.la" )
> libtool: link: (cd .libs/libcee.lax/liba.a && ar x
> /home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/liba.a)
> libtool: link: (cd .libs/libcee.lax/libb.a && ar x
> /home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/libb.a)
> libtool: link: f77 -shared -expect_unresolved \* .libs/c.o
> .libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o-msym -soname
> libcee.so.0 `test -n "0.0.0:0.0" && print -r "X-set_version 0.0.0:0.0" |
> /usr/bin/sed -e 1s/^X//` -update_registry .libs/so_locations -o
> .libs/libcee.so.0.0.0
> f77: Severe: Invalid file name - must be of the form name.suffix : *
> ./convenience.at:108: $LIBTOOL --tag=F77 --mode=link $F77 $FFLAGS $LDFLAGS
> -static -o main_static main.lo libcee.la
> stderr:
> libtool: link: cannot find the library `libcee.la' or unhandled argument
> `libcee.la'
> stdout:
> ./convenience.at:108: exit code was 1, expected 0
> 9. convenience.at:74: 9. F77 convenience archives (convenience.at:74): FAILED
> (convenience.at:108)
>
> # -*- compilation -*-
> 10. convenience.at:116: testing ...
> ./convenience.at:117: test -n "$FC" || (exit 77)
> libtool: compile: f95 -c -g a.f -o .libs/a.o
> libtool: compile: f95 -c -g a.f -o a.o >/dev/null 2>&1
> libtool: compile: f95 -c -g b.f -o .libs/b.o
> libtool: compile: f95 -c -g b.f -o b.o >/dev/null 2>&1
> libtool: compile: f95 -c -g c.f -o .libs/c.o
> libtool: compile: f95 -c -g c.f -o c.o >/dev/null 2>&1
> libtool: compile: f95 -c -g main.f -o .libs/main.o
> libtool: compile: f95 -c -g main.f -o main.o >/dev/null 2>&1
> libtool: link: ar cru .libs/liba.a .libs/a.o
> libtool: link: ranlib .libs/liba.a
> libtool: link: creating liba.la
> libtool: link: ( cd ".libs" && rm -f "liba.la" && ln -s "../liba.la"
> "liba.la" )
> libtool: link: ar cru .libs/libb.a .libs/b.o
> libtool: link: ranlib .libs/libb.a
> libtool: link: creating libb.la
> libtool: link: ( cd ".libs" && rm -f "libb.la" && ln -s "../libb.la"
> "libb.la" )
> libtool: link: (cd .libs/libcee.lax/liba.a && ar x
> /home/njoly/temp/libtool/tests/testsuite.dir/10/./.libs/liba.a)
> libtool: link: (c
more useful installcheck (was: HEAD: cross-compile test new testsuite)
Hi Gary,
* Gary V. Vaughan wrote on Wed, Oct 05, 2005 at 03:37:17PM CEST:
> Gary V. Vaughan wrote:
> >@@ -0,0 +1 @@
> >+libtoolize: $pkgltdldir not a directory:
> >`/Users/gary/devel/savannah/libtool/+inst/share/libtool'
> >--- expout 2005-10-05 14:24:22.0 +0100
> >+++
>
> Looks like an automake bug. If I change $(abs_top_srcdir) in Makefile.am
> to @abs_top_srcdir@, then everything works as expected.
>
> If you agree with my diagnosis, please commit a fix, and file a bug on
> [EMAIL PROTECTED]
Well, Alexandre is aware of the issue, I believe, as this has been
discussed before on bug-automake:
http://sourceware.org/ml/bug-automake/2005/msg00572.html
In order to be able to fix another couple of items, I propose to go back
to my INSTALLCHECK_ENVIRONMENT, and use the workaround described in the
thread above, to fix this:
- LIBTOOL and LIBTOOLIZE point to the installed scripts during `make
installcheck'.
- fix installcheck (mostly) for transformed program names.
- try to unset both before invoking `make -e', else we won't test the
libtool scripts generated by the tests. Strictly speaking, this is
orthogonal, as it has been an issue before. It does break down on
shells without `unset', none of which are to be found on anything
Libtool is reasonably interested in (and even then, we don't fail,
we only test less thoroughly).
OK to apply? I believe following the `make -e' approach is less error-
prone than remembering to set all variables for sub-makes in the
Makefile.
Cheers,
Ralf
* configure.ac (abs_top_builddir, abs_top_srcdir): always
substitute.
* Makefile.am (BUILDCHECK_ENVIRONMENT)
(INSTALLCHECK_ENVIRONMENT): New macros. Set _lt_pkgdatadir,
LIBTOOL, LIBTOOLIZE accordingly, by using above, and
program_transform_name.
* tests/testsuite.at (TESTS_PREPARE): Do not set them anymore.
Set $unset.
(LT_AT_MAKE): Use to unset LIBTOOL and LIBTOOLIZE.
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.171
diff -u -r1.171 Makefile.am
--- Makefile.am 5 Oct 2005 15:02:54 - 1.171
+++ Makefile.am 6 Oct 2005 15:13:35 -
@@ -493,6 +493,14 @@
FC="$(FC)" FCFLAGS="$(FCFLAGS)" \
GCJ="$(GCJ)" GCJFLAGS="$(GCJFLAGS)"
+BUILDCHECK_ENVIRONMENT = _lt_pkgdatadir="$(abs_top_srcdir)" \
+ LIBTOOLIZE="$(abs_top_builddir)/libtoolize" \
+ LIBTOOL="$(abs_top_builddir)/libtool"
+
+INSTALLCHECK_ENVIRONMENT = \
+ LIBTOOLIZE="$(bindir)/`echo libtoolize | sed
'$(program_transform_name)'`" \
+ LIBTOOL="$(bindir)/`echo libtool | sed '$(program_transform_name)'`"
+
check-recursive: $(srcdir)/$(TESTSUITE)
# Use `$(srcdir)' for the benefit of non-GNU makes: this is
@@ -521,12 +529,12 @@
# Hook the test suite into the check rule
check-local: tests/atconfig $(srcdir)/$(TESTSUITE)
$(CD_TESTDIR); \
- $(TESTS_ENVIRONMENT) _lt_pkgdatadir="$$abs_srcdir" $(SHELL)
$$abs_srcdir/$(TESTSUITE) $(TESTSUITE_FLAGS)
+ $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) $(SHELL)
$$abs_srcdir/$(TESTSUITE) $(TESTSUITE_FLAGS)
# Run the test suite on the *installed* tree.
installcheck-local:
$(CD_TESTDIR); \
- $(TESTS_ENVIRONMENT) $(SHELL) $$abs_srcdir/$(TESTSUITE)
$(TESTSUITE_FLAGS) AUTOTEST_PATH=$(exec_prefix)/bin
+ $(TESTS_ENVIRONMENT) $(INSTALLCHECK_ENVIRONMENT) $(SHELL)
$$abs_srcdir/$(TESTSUITE) $(TESTSUITE_FLAGS) AUTOTEST_PATH=$(exec_prefix)/bin
# We need to remove any file droppings left behind by testsuite
clean-local: clean-local-legacy
Index: configure.ac
===
RCS file: /cvsroot/libtool/libtool/configure.ac,v
retrieving revision 1.73
diff -u -r1.73 configure.ac
--- configure.ac26 Sep 2005 12:04:46 - 1.73
+++ configure.ac6 Oct 2005 15:13:35 -
@@ -134,6 +134,9 @@
## Libtool specific configuration. ##
## --- ##
+dnl automake-1.9 does not substitute these two by default
+AC_SUBST([abs_top_srcdir])
+AC_SUBST([abs_top_builddir])
AC_SUBST([aclocaldir], ["\${datadir}/aclocal"])
AC_SUBST([pkgdatadir], ["\${datadir}/$PACKAGE"])
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.24
diff -u -r1.24 testsuite.at
--- tests/testsuite.at 5 Oct 2005 15:02:54 - 1.24
+++ tests/testsuite.at 6 Oct 2005 15:13:35 -
@@ -19,14 +19,12 @@
# 02110-1301, USA.
m4_divert_push([PREPARE_TESTS])dnl
-: ${LIBTOOLIZE="${abs_top_builddir}/libtoolize"}
-: ${LIBTOOL="${abs_top_builddir}/libtool"}
: ${ACLOCAL=aclocal}
: ${AUTOHEADER=autoheader}
: ${AUTOCONF=autoconf}
: ${AUTOMAKE=automake}
: ${AUTORECONF=autoreconf}
-export LIBTOOLIZE LIBTOOL ACLOCAL AUTOHEADER AUTOCONF AUTOMAKE AUTORECONF
+export ACLOCAL AUTOHEADE
Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure)
Hi Nicolas,
* Nicolas Joly wrote on Thu, Oct 06, 2005 at 03:00:51PM CEST:
> On Thu, Oct 06, 2005 at 02:27:26PM +0200, Ralf Wildenhues wrote:
> > * Nicolas Joly wrote on Wed, Oct 05, 2005 at 03:22:10PM CEST:
> > >
> > > Got 3 failures; log attached.
> >
> > The first one I can't explain yet (Gary?)
>
> Don;t worry to much about it. I updated CVS libtool in the mean time,
> and this one is gone.
Cool!
> > For the rest of this mail, I assume this link has suitable(?)
> > documentation for these Fortran compilers:
> > http://h21007.www2.hp.com/dspp/files/unprotected/Fortran/docs/unix-um/dfumtoc.htm
> >
> > data points:
> > - the doc mentions that undefined symbols are not allowed -- but ld(1)
> > says otherwise. Maybe it works with
> > allow_undefined_flag="\${wl}-expect_unresolved \${wl}\*"
> > or, if it doesn't, we need to set
> > allow_undefined_flag=unsupported
> > - all of `-soname ..', `-msym', `-set_version ..', `-update_registry ..'
> > seem unsupported by f77/f95, but I believe they should be supplied to
> > ld by prefixing ${wl} everywhere -- not really sure, though.
>
> It seems correct.
Good.
> Tru64 fortran compilers do not support `-expect_unresolved \*' option
> directly. Passing it prefixed with `-Wl,' solves the problem.
>
> All others seems to work directly :
*snip*
Very nice, thanks for testing!
> > This suggests that it should be possible to write archive_cmds (and
> > possibly archive_expsyms_cmds) in libltdl/m4/libtool.m4:_LT_LINKER_SHLIBS
> > like a mixture of the $GCC and the non-$GCC case, using $cc_basename and
> > $GCC as decision criteria. Would you be willing to work on this?
>
> I'll try, even if i'm not a fortran programmer myself.
>
> > Should I create a preliminary patch you could test?
>
> Yes, please.
See below. If all the C compiler does is pass `-expect_unresolved pattern'
through to the linker anyway, we could also just skip the `case' thingy
and add the `${wl}' every time..
> > Is there also a `f90' available on this platform?
>
> f90 - invokes the Compaq Fortran 90 (formerly DIGITAL Fortran 90) compiler
> f95 - invokes the Compaq Fortran 95 (formerly DIGITAL Fortran 95) compiler
> f77 - invokes the Compaq Fortran 90 (formerly DIGITAL Fortran 90) compiler
> f77 -old_f77 - invokes the Compaq Fortran 77 (formerly DIGITAL Fortran 77)
> compiler
Cheers,
Ralf
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.25
diff -u -r1.25 libtool.m4
--- libltdl/m4/libtool.m4 5 Oct 2005 15:57:05 - 1.25
+++ libltdl/m4/libtool.m4 6 Oct 2005 16:25:31 -
@@ -4472,7 +4472,12 @@
_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$libobjs $deplibs $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n
"$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
else
- _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
+ case $cc_basename in
+ f77* | f90* | f95*)
+ _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved
${wl}\*' ;;
+ *)
+ _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*' ;;
+ esac
_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$libobjs $deplibs $compiler_flags -msym -soname $soname `test -n "$verstring"
&& $ECHO "X-set_version $verstring" | $Xsed` -update_registry
${output_objdir}/so_locations -o $lib'
_LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do
printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; printf "%s\\n"
"-hidden">> $lib.exp~
$CC -shared${allow_undefined_flag} -input $lib.exp $compiler_flags
$libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "X-set_version
$verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib~$RM
$lib.exp'
Re: more useful installcheck
Hi Gary, * Gary V. Vaughan wrote on Fri, Oct 07, 2005 at 10:41:56AM CEST: > > Ralf Wildenhues wrote: > >OK to apply? > > Nice patch. Yes, please :-) Done. Thanks! Cheers, Ralf > >* configure.ac (abs_top_builddir, abs_top_srcdir): always > >substitute. > >* Makefile.am (BUILDCHECK_ENVIRONMENT) > >(INSTALLCHECK_ENVIRONMENT): New macros. Set _lt_pkgdatadir, > >LIBTOOL, LIBTOOLIZE accordingly, by using above, and > >program_transform_name. > >* tests/testsuite.at (TESTS_PREPARE): Do not set them anymore. > >Set $unset. > >(LT_AT_MAKE): Use to unset LIBTOOL and LIBTOOLIZE.
Re: Support for creating shared C++ libraries on BeOS
Hi Christian,
* Christian Biesinger wrote on Sun, Oct 09, 2005 at 03:41:42AM CEST:
> Hi,
> the attached patch fixes (implements) C++ support for shared libraries
> on BeOS. It just copies the C part to the C++ section; this works fine,
> I tested on Zeta.
Thank you for the patch!
> The patch was made against libtool 1.5.16; it seems to apply to 1.5.20
> as well.
>
> Would be great if you could check it in. Looking at branch-2-0, it seems
> that the same idea can be applied there, as well as on HEAD (assuming
> libltdl/m4/libtool.m4 is the right file to look at).
branch-2-0 is dead, 2.0 will be released from what is now CVS HEAD.
I have checked in the following patches to CVS HEAD and branch-1-5,
respectively.
Maybe you could take a look at the FIXME mentioned? Also, we love to
see testsuite output.. ;-)
Cheers,
Ralf
CVS HEAD:
2005-10-09 Christian Biesinger <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [ beos ]:
Initial shared library support for C++.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.25
diff -u -r1.25 libtool.m4
--- libltdl/m4/libtool.m4 5 Oct 2005 15:57:05 - 1.25
+++ libltdl/m4/libtool.m4 9 Oct 2005 06:22:50 -
@@ -5172,6 +5172,18 @@
fi
fi
;;
+
+ beos*)
+ if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null;
then
+ _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
+ # Joseph Beckenbach <[EMAIL PROTECTED]> says some releases of gcc
+ # support --undefined. This deserves some investigation. FIXME
+ _LT_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+ else
+ _LT_TAGVAR(ld_shlibs, $1)=no
+ fi
+ ;;
+
chorus*)
case $cc_basename in
*)
branch-1-5:
2005-10-09 Christian Biesinger <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG) [ beos ]:
Initial shared library support for C++.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.114
diff -u -r1.314.2.114 libtool.m4
--- libtool.m4 5 Oct 2005 15:57:28 - 1.314.2.114
+++ libtool.m4 9 Oct 2005 06:23:35 -
@@ -2940,6 +2940,18 @@
fi
fi
;;
+
+ beos*)
+if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+ # Joseph Beckenbach <[EMAIL PROTECTED]> says some releases of gcc
+ # support --undefined. This deserves some investigation. FIXME
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+else
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+fi
+;;
+
chorus*)
case $cc_basename in
*)
@@ -2948,7 +2960,6 @@
;;
esac
;;
-
cygwin* | mingw* | pw32*)
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
Re: [patch 00/19] @patch@ Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:24PM CEST: > Hallo Ralf, Hey, I'm not the only one that can accept or reject patches.. ;-) But I'll try to address as many of these as quickly as possible. > Here is my queue of unapplied patches, regenerated against current > CVS HEAD, and which between them address all but one of the release > blockers listed here: *snip* Wow. I'm quite impressed! 8-) > Looking forward to making the alpha release, Yep, me too. I've got a handful of own patches sitting here, which I'd like to push out before, but I'll probably agree to drop anything that will cost me more than a couple of days to push out. Thank you very much, Ralf
Re: [patch 17/19] 287-gary-implicit-libtoolize-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:41PM CEST: > An ill conceived idea to save typing the --ltdl flag all the time. This is the easiest to address: Rejected. :-) Rationale: I want to be able to m4_if([some_condition], [LT_CONFIG_LTDL_DIR $other_LTDL_configuration ]) and preventing that in order to save typing an option isn't worth much hassle. Would you agree? Cheers, Ralf > doc/libtool.texi |5 - > libtoolize.m4sh |5 + > 2 files changed, 9 insertions(+), 1 deletion(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Support implicit --ltdl when LT_CONFIG_LTDL_DIR > is present, but names an as-yet empty directory. > * doc/libtool.texi (Invoking libtoolize): Document it. *snip*
Re: [patch 15/19] 299-gary-refactor-autotests.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:39PM CEST:
> tests/old-m4-iface.at | 64 ---
> tests/standalone.at | 80 +--
> tests/subproject.at | 85 --
> tests/testsuite.at| 91
> ++
> 4 files changed, 102 insertions(+), 218 deletions(-)
Approved (after its requirements are in, if any), except for one nit,
see below inline.
Oh, if you were bored, you could
_LTDL_PROJECT_FILES([with-or-without-Makefile])
but really I don't care.
Cheers,
Ralf
*snip part*
> Index: libtool--devo--1.0/tests/standalone.at
> ===
> --- libtool--devo--1.0.orig/tests/standalone.at
> +++ libtool--devo--1.0/tests/standalone.at
> @@ -73,84 +73,8 @@ AT_CLEANUP
>
> AT_SETUP([linking libltdl without autotools])
>
> -AT_DATA([module.c],
> -[[const char *
> -hello (void)
> -{
> - return "Hello!";
> -}
> -]])
> -
> -AT_DATA([main.c],
> -[[#include
> -#include "ltdl.h"
> -
> -int
> -main (int argc, char **argv)
> -{
> - lt_dlhandle handle;
> - const char *(*func) (void) = 0;
> - int status = 1;
> -
> - LTDL_SET_PRELOADED_SYMBOLS();
> - if (lt_dlinit() != 0) {
> -fprintf (stderr, "error during initialisation: %s\n", lt_dlerror());
> -return 1;
> - }
> -
> - handle = lt_dlopen("module.la");
> - if (!handle) {
> -fprintf (stderr, "error dlopening module.la: %s\n", lt_dlerror());
> -goto finish;
> - }
> -
> - func = (const char *(*)(void)) lt_dlsym (handle, "hello");
> - if (!func) {
> -fprintf (stderr, "error fetching func: %s\n", lt_dlerror());
> -goto finish;
> - }
> -
> - printf ("%s\n", (*func) ());
> - status = 0;
> -
> -finish:
> - lt_dlexit();
> -
> - return status;
> -}
> -]])
> -
> -AT_DATA([Makefile],
> -[[LIBTOOL= ./libltdl/libtool
> -INCLUDES = -I./libltdl
> -MODFLAGS = -module -avoid-version -no-undefined
> -
> -LTCOMPILE = $(LIBTOOL) --tag=CC $(LIBTOOLFLAGS) --mode=compile \
> -$(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)
> -LTLINK= $(LIBTOOL) --tag=CC $(LIBTOOLFLAGS) --mode=link \
> -$(CC) $(CFLAGS) $(LDFLAGS)
> -
> -TARGETS = libltdl/libltdlc.la module.la ltdldemo$(EXEEXT)
> -
> -all: $(TARGETS)
> -
> -$(LIBTOOL) libltdl/libltdlc.la:
> - cd libltdl && ./configure $(CONFIGURE_OPTIONS) && $(MAKE)
> -
> -ltdldemo$(EXEEXT): $(LIBTOOL) module.la libltdl/libltdlc.la main.lo
> - $(LTLINK) -o ltdldemo main.lo -dlopen module.la ./libltdl/libltdlc.la
> -
> -main.lo: $(LIBTOOL) main.c
> - $(LTCOMPILE) -c main.c
> -
> -module.la: $(LIBTOOL) module.lo
> - $(LTLINK) -o module.la module.lo $(MODFLAGS) -rpath /dev/null
> -
> -module.lo: $(LIBTOOL) module.c
> - $(LTCOMPILE) -c module.c
> -]])
> -
> -LT_AT_LIBTOOLIZE([--copy --ltdl])
> +_LTDL_PROJECT_FILES
> +LT_AT_LIBTOOLIZE([--copy --ltdl=sub/ltdl])
Why did you change `--ltdl' to `--ltdl=sub/ltdl' here?
IMO better to leave as-is, unless there is a compelling reason against
it. (We have to support plain `--ltdl' for backward compatibility.)
> LT_AT_MAKE([], [CC="$CC" LIBTOOLFLAGS="$LIBTOOLFLAGS" CPPFLAGS="$CPPFLAGS" \
> CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" \
> CONFIGURE_OPTIONS="$configure_options"])
*snip part*
Re: [patch 18/19] 300-gary-simplify-tests.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:42PM CEST: > tests/old-m4-iface.at |7 +++ > tests/subproject.at | 12 +++- > tests/testsuite.at|6 +++--- > 3 files changed, 9 insertions(+), 16 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * tests/testsuite.at (LT_AT_BOOTSTRAP): Allow passing arguments to > configure. > * tests/old-m4-iface.at, tests/subproject.at: Use LT_AT_BOOTSTRAP./ Why not rather LT_AT_BOOTSTRAP([LIBTOOLIZE-ARGS], [AUTORECONF-ARGS], [CONFIGURE-ARGS]) ? If you agree, please go ahead and commit a change to that extent. Rationale: I would like some tests to not have `--force', for example; also `--ltdl' would be necessary as per my other reject. The old-m4-iface.at change is fine. If you're bored, you could also fix Makefile.am, testsuite.at to point $macrodir to the installed directory for `installcheck'.. Cheers, Ralf > Index: libtool--devo--1.0/tests/old-m4-iface.at > === > --- libtool--devo--1.0.orig/tests/old-m4-iface.at > +++ libtool--devo--1.0/tests/old-m4-iface.at > @@ -71,10 +71,9 @@ LT_AT_LIBTOOLIZE([--install]) > > # This is slightly bogus, since only libtool.m4 was required in aclocal.m4 > # with libtool-1.5x... > -test -f aclocal.m4 \ > -|| cat "$macrodir/libtool.m4" "$macrodir/ltoptions.m4" \ > - "$macrodir/ltsugar.m4" "$macrodir/ltversion.m4" > aclocal.m4 \ > -|| exit 1 > +AT_CHECK([test -f aclocal.m4 || > + cat "$macrodir/libtool.m4" "$macrodir/ltoptions.m4" \ > + "$macrodir/ltsugar.m4" "$macrodir/ltversion.m4" > aclocal.m4]) > > LT_AT_AUTOCONF([--force]) > LT_AT_CONFIGURE > Index: libtool--devo--1.0/tests/subproject.at > === > --- libtool--devo--1.0.orig/tests/subproject.at > +++ libtool--devo--1.0/tests/subproject.at > @@ -51,9 +51,7 @@ touch foo.c > AT_SETUP([compiling softlinked libltdl]) > > _LTDL_SETUP > -LT_AT_LIBTOOLIZE([--ltdl]) > -LT_AT_AUTORECONF([--force --verbose --install]) > -LT_AT_CONFIGURE > +LT_AT_BOOTSTRAP > LT_AT_MAKE > > AT_CHECK([test -f sub/ltdl/libltdlc.la]) > @@ -68,9 +66,7 @@ AT_CLEANUP > AT_SETUP([compiling copied libltdl]) > > _LTDL_SETUP > -LT_AT_LIBTOOLIZE([--copy --ltdl]) > -LT_AT_AUTORECONF([--force --verbose --install]) > -LT_AT_CONFIGURE > +LT_AT_BOOTSTRAP > LT_AT_MAKE > > AT_CHECK([test -f sub/ltdl/libltdlc.la]) > @@ -87,9 +83,7 @@ AT_SETUP([installable libltdl]) > prefix=`pwd`/_inst > > _LTDL_SETUP > -LT_AT_LIBTOOLIZE([--copy --ltdl]) > -LT_AT_AUTORECONF([--force --verbose --install]) > -LT_AT_CONFIGURE([--enable-ltdl-install --prefix=$prefix]) > +LT_AT_BOOTSTRAP([--enable-ltdl-install --prefix=$prefix]) > LT_AT_MAKE([all install]) > > AT_CHECK([test -f $prefix/lib/libltdl.la]) > Index: libtool--devo--1.0/tests/testsuite.at > === > --- libtool--devo--1.0.orig/tests/testsuite.at > +++ libtool--devo--1.0/tests/testsuite.at > @@ -91,12 +91,12 @@ m4_define([LT_AT_MAKE], > ]) > > > -# LT_AT_BOOTSTRAP > -# --- > +# LT_AT_BOOTSTRAP([CONFIGURE-ARGS]) > +# - > m4_define([LT_AT_BOOTSTRAP], > [LT_AT_LIBTOOLIZE([--copy]) > LT_AT_AUTORECONF([--force --verbose --install]) > -LT_AT_CONFIGURE > +LT_AT_CONFIGURE([$1]) > ])
Re: [patch 07/19] 291-gary-centralise-INCLTDL.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:31PM CEST: > libltdl/m4/ltdl.m4 | 19 +-- > 1 files changed, 5 insertions(+), 14 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/ltdl.m4 (LTDL_CONVENIENCE, LTDL_INSTALLABLE): Remove > AC_SUBST of LIBLTDL, LTDLINCL, and all mention of INCLTDL. > (LT_WITH_LTDL): Due to order constraints between LTDL_CONVENIENCE, > LTDL_INSTALLABLE, LT_WITH_LTDL & LTDL_INIT, we can safely AC_SUBST > LIBLTDL and LTDLINCL here. Also, remember to synch INCLTDL. Nice patch! Please apply. Cheers, Ralf
Re: [patch 09/19] 293-gary-default-convenience-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:33PM CEST: > libltdl/m4/ltdl.m4 |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/ltdl.m4 (LTDL_INIT): Call _LT_ENABLE_INSTALL directly > instead of m4_requiring it, as it relies on enable_ltdl_install > and enable_ltdl_convenience to have been initialised first. Why and when can this happen? We should think about adding a test to check whether `configure' has the order correctly here (plus maybe documentation and AC_BEFORE instances in case there are ordering issues hidden here); but I'd like to understand the problem first. Cheers, Ralf > Index: libtool--devo--1.0/libltdl/m4/ltdl.m4 > === > --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4 > +++ libtool--devo--1.0/libltdl/m4/ltdl.m4 > @@ -247,9 +247,12 @@ AC_REQUIRE([gl_FUNC_ARGZ])dnl > > m4_require([_LT_CHECK_OBJDIR])dnl > m4_require([_LT_HEADER_DLFCN])dnl > -m4_require([_LT_ENABLE_INSTALL])dnl > m4_require([_LT_CHECK_DLPREOPEN])dnl > > +dnl Don't require this, or it will be expanded earlier that the code > +dnl that sets the variables it relies on: > +_LT_ENABLE_INSTALL > + > dnl Although deprecated and no longer documented, alpha releases of > dnl libtool used to define an LTDL_INIT to take a DIRECTORY orgument. > dnl If LT_CONFIG_LTDL_DIR was called already, but LTDL_INIT was given a > @@ -297,7 +300,7 @@ dnl AC_DEFUN([AC_LIB_LTDL], []) > > # _LT_ENABLE_INSTALL > # -- > -m4_defun([_LT_ENABLE_INSTALL], > +m4_define([_LT_ENABLE_INSTALL], > [AC_ARG_ENABLE([ltdl-install], > [AS_HELP_STRING([--enable-ltdl-install], [install libltdl])])
Re: [patch 14/19] 298-gary-document-libltdl-build-modes.diff Queue
Hi Gary,
Reading the documentation is easier than checking its implementation. :)
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:38PM CEST:
> doc/libtool.texi | 92
> +--
> 1 files changed, 90 insertions(+), 2 deletions(-)
OK when nits and comments below addressed and requirements committed. :-)
By the way, I'm pretty sure the documentation will hopelessly ask to
much of a newbie (or non-Autotools expert FWIW). But improving on that
(without backwards incompatibility) after the alpha release should be
easily possible, including some other outstanding doc patches.
Cheers,
Ralf
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * tests/testsuite.at (_LTDL_PROJECT_FILES): Factored out from
> common code to build a basic libltdl using project.
> * tests/old-m4-iface.at, tests/standalone.at, tests/subproject.at:
> Use it.
This ChangeLog part belongs to a different patch (and is missing there).
> * doc/libtool.texi (Distributing libltdl): Document correct use of
> LT_CONFIG_LTDL_DIR mode argument with Autoconf and Automake.
>
> Index: libtool--devo--1.0/doc/libtool.texi
> ===
> --- libtool--devo--1.0.orig/doc/libtool.texi
> +++ libtool--devo--1.0/doc/libtool.texi
> @@ -4186,10 +4186,98 @@ or against both a local convenience libr
> is bad. Ensuring that only one copy of the libltdl sources are linked
> into any program is left as an exercise for the reader.
>
> [EMAIL PROTECTED] LT_CONFIG_LTDL_DIR (@var{DIRECTORY})
> [EMAIL PROTECTED] LT_CONFIG_LTDL_DIR (@var{DIRECTORY}. @var{LTDL-MODE})
> Declare @var{DIRECTORY} to be the location of the @code{libltdl}
> source files, for @command{libtoolize --ltdl} to place
> -them. @xref{Invoking libtoolize}, for more details.
> +them. @xref{Invoking libtoolize}, for more details. Providing that you
better(?): Provided
> +add an appropriate @code{LT_CONFIG_LTDL} call in your
> [EMAIL PROTECTED] before calling @command{libtoolize}, then the
s/then // would be better, IMVHO.
> +appropriate @code{libltdl} files will be installed automatically without
> +manually specifying the mode to @command{libtoolize} explicitly.
> +
> [EMAIL PROTECTED] can be either @samp{nonrecursive}, @samp{recursive}, or
> [EMAIL PROTECTED] depending on how you wish for your project to build
> [EMAIL PROTECTED]:
> +
> [EMAIL PROTECTED] @samp
> [EMAIL PROTECTED] nonrecursive
> +This is how the Libtool project distribution builds the @code{libltdl}
> +we ship and install. If you wish to use Automake to build
> [EMAIL PROTECTED] without invoking a recursive make to descend into the
> [EMAIL PROTECTED] subdirectory, then use this option. You will need to set
> +your configuration up carefully to make this work properly, and you will
> +need a release of Automake that supports @code{subdir-objects}. In your
> [EMAIL PROTECTED], add:
Isn't the following more correct?
.. you will need releases of Autoconf and Automake that support
@code{subdir-objects} and @code{LIBOBJDIR} properly.
> +
> [EMAIL PROTECTED]
> +LT_CONFIG_LTDL_DIR([libltdl], [nonrecursive])
> +AM_PROG_CC_C_O
> +AM_INIT_AUTOMAKE([subdir-objects])
> +LT_WITH_LTDL
> [EMAIL PROTECTED] example
For safety, we should add `AC_PROG_CC' before `AM_PROG_CC_C_O'.
Is it necessary to add LT_CONFIG_LTDL_DIR before AM_INIT_AUTOMAKE
(if yes, then the former should have an AC_BEFORE warning to this end).
If not (which I think), then we should not do so. So then we would end
up like this:
AM_INIT_AUTOMAKE([subdir-objects])
AC_PROG_CC
AM_PROG_CC_C_O
LT_CONFIG_LTDL_DIR([libltdl], [nonrecursive])
LT_WITH_LTDL
Rationale: people just _love_ to keep macros corresponding to different
packages separated. We even do this ourseleves, in toplevel configure.ac
(except for the `LT_CONFIG_LTDL_DIR' call you added).
People will have a hard time understanding that LT_CONFIG_LTDL_DIR
should be separated from the rest of all the Libtool/libltdl related
macros. Any requirements should be diagnosed if possible, or an endless
stream of bug reports is predictable..
> +
> [EMAIL PROTECTED]
> +And add the following near the top of your @file{Makefile.am}:
> +
> [EMAIL PROTECTED]
> +BUILT_SOURCES =
> +EXTRA_DIST =
> +CLEANFILES =
> +MOSTLYCLEANFILES =
> +
> +include libltdl/Makefile.inc
> [EMAIL PROTECTED] example
> +
> [EMAIL PROTECTED]
> +Unless you don't build any other libraries from this @file{Makefile.am},
> +you will also need to change @code{lib_LTLIBRARIES} to assign with
> [EMAIL PROTECTED] so that the @code{libltdl} targets declared in
> [EMAIL PROTECTED] are not overwritten.
Hmm. Why not have the user add
noinst_LTLIBRARIES =
lib_LTLIBRARIES =
EXTRA_LTLIBRARIES =
as well? Extensibility-wise, this is saner -- think of several
packages like `libltdl', put together.
Come to think of, I'm not sure whether we should change these:
DEFS
AM
Re: [patch 13/19] 297-gary-LT_WITH_LTDL-recursive.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:37PM CEST: > libltdl/m4/ltdl.m4 |3 ++- > 1 files changed, 2 insertions(+), 1 deletion(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > Support 'recursive' mode for building libltdl: Automake will > recursively descend into the libltdl directory, and use libltdl's > Makefile.am code to build libltdl: > * ltdl.m4 (LT_CONFIG_LTDL_DIR): Don't barf on 'recursive' mode > for 2nd argument. > (_LTDL_MODE_DISPATCH): Handle recursive mode. OK after prerequisites. Cheers, Ralf > Index: libtool--devo--1.0/libltdl/m4/ltdl.m4 > === > --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4 > +++ libtool--devo--1.0/libltdl/m4/ltdl.m4 > @@ -34,7 +34,7 @@ m4_popdef([_ARG_DIR]) > dnl If not otherwise defined, default to the 1.5.x compatible subproject > mode: > m4_if(_LTDL_MODE, [], > [m4_define([_LTDL_MODE], m4_default([$2], [subproject])) > - m4_if([-1], [m4_bregexp(_LTDL_MODE, [\(subproject\|nonrecursive\)])], > + m4_if([-1], [m4_bregexp(_LTDL_MODE, > [\(subproject\|\(non\)?recursive\)])], > [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])]) > ])# LT_CONFIG_LTDL_DIR > > @@ -141,6 +141,7 @@ m4_if(_LTDL_DIR, [], > [subproject], [AC_CONFIG_SUBDIRS(_LTDL_DIR) > _LT_SHELL_INIT([lt_dlopen_dir="$lt_ltdl_dir"])], > [nonrecursive], [_LT_SHELL_INIT([lt_dlopen_dir="$lt_ltdl_dir"])], > + [recursive], [], > [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])])dnl > dnl Be careful not to expand twice: > m4_define([$0], [])
Re: [patch 08/19] 292-gary-remove-spurious-quotes.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:32PM CEST:
> libltdl/m4/ltdl.m4 |2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libltdl/m4/ltdl.m4 (_LT_ENABLE_INSTALL): Remove bogus extra
> closing brackets.
Yes, please commit right away, and also fix the same bug with
AC_LTDL_ENABLE_INSTALL in branch-1-5.
I have a slight feeling of deja-vu, we've fixed something similar
before, but can't find good terms to search for the previous change.
Do you have editor macros which balance m4 quotes for you?
Thanks!
Ralf
> Index: libtool--devo--1.0/libltdl/m4/ltdl.m4
> ===
> --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4
> +++ libtool--devo--1.0/libltdl/m4/ltdl.m4
> @@ -303,7 +303,7 @@ m4_defun([_LT_ENABLE_INSTALL],
>
> AM_CONDITIONAL(INSTALL_LTDL, test x"${enable_ltdl_install-no}" != xno)
> AM_CONDITIONAL(CONVENIENCE_LTDL, test x"${enable_ltdl_convenience-no}" !=
> xno)
> -])])# _LT_ENABLE_INSTALL
> +])# _LT_ENABLE_INSTALL
>
>
> # LT_SYS_DLOPEN_DEPLIBS
Re: [patch 10/19] 294-gary-libltdl-configure-messages.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:34PM CEST: > Don't do this anymore: > > checking for ltdl.h... yes > checking for lt_dlinterface_register in -lltdl... checking for > lt_dlinterface_register in ltdl.h... no > no > checking whether to use included libltdl... yes > > libltdl/m4/ltdl.m4 |2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/ltdl.m4 (LT_WITH_LTDL): Don't nest AC_MSG_CHECKING/ > AC_MSG_RESULT pairs. OK right away. Thank you! Ralf > Index: libtool--devo--1.0/libltdl/m4/ltdl.m4 > === > --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4 > +++ libtool--devo--1.0/libltdl/m4/ltdl.m4 > @@ -171,7 +171,6 @@ AC_ARG_WITH([included_ltdl], > if test "x$with_included_ltdl" != xyes; then ># We are not being forced to use the included libltdl sources, so ># decide whether there is a useful installed version we can use. > - AC_MSG_CHECKING([for lt_dlinterface_register in ltdl.h]) >lt_dlinterface_register_found=no >AC_CHECK_HEADER([ltdl.h], >[AC_CHECK_LIB([ltdl], [lt_dlinterface_register], > @@ -181,6 +180,7 @@ if test "x$with_included_ltdl" != xyes; >[], >[AC_INCLUDES_DEFAULT] >) > + AC_MSG_CHECKING([for lt_dlinterface_register in ltdl.h]) >test "x$with_included_ltdl" = xno && lt_dlinterface_register_found=yes >AC_MSG_RESULT([$lt_dlinterface_register_found]) > fi
Re: [patch 11/19] 295-gary-dont-force-ac-config-headers-on-subproject-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:35PM CEST: > libltdl/m4/ltdl.m4| 12 > tests/old-m4-iface.at |1 - > 2 files changed, 8 insertions(+), 5 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/ltdl.m4 (LTDL_INIT): Don't force running > AC_CONFIG_HEADERS for subproject ltdl. > * tests/old-m4-iface.at: Remove workaround. OK after prerequisites are in, and see nit below. Cheers, Ralf > Index: libtool--devo--1.0/libltdl/m4/ltdl.m4 > === > --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4 > +++ libtool--devo--1.0/libltdl/m4/ltdl.m4 > @@ -274,10 +274,14 @@ _LTDL_MODE_DISPATCH > AC_CONFIG_COMMANDS_PRE([dnl > m4_pattern_allow([^LT_CONFIG_H$])dnl > m4_ifset([AH_HEADER], > - [LT_CONFIG_H=AH_HEADER], > - [m4_ifset([AC_LIST_HEADERS], > -[LT_CONFIG_H=`echo "AC_LIST_HEADERS" | $SED 's,^[[ > ]]*,,;s,[[ :]].*$,,'`], > -[LT_CONFIG_H=config.h;AC_CONFIG_HEADERS([config.h])])])]) > +[LT_CONFIG_H=AH_HEADER], > +[m4_ifset([AC_LIST_HEADERS], > + [LT_CONFIG_H=`echo "AC_LIST_HEADERS" | $SED 's,^[[ ]]*,,;s,[[ > :]].*$,,'`], > + [LT_CONFIG_H=config.h > + dnl subproject mode libltdl has its own config.h... > + m4_if(_LTDL_MODE, [subproject], > + [], > + [AC_CONFIG_HEADERS([config.h])])])])]) Should we AC_CONFIG_HEADERS([config.h:config-h.in]) for filesystem portability? > AC_SUBST([LT_CONFIG_H]) > > AC_CHECK_HEADERS([memory.h unistd.h dl.h sys/dl.h dld.h mach-o/dyld.h], > Index: libtool--devo--1.0/tests/old-m4-iface.at > === > --- libtool--devo--1.0.orig/tests/old-m4-iface.at > +++ libtool--devo--1.0/tests/old-m4-iface.at > @@ -182,7 +182,6 @@ foo (const char *str) > } > ]]) > > -touch config.h.in # bug in current ltdl.m4 > LT_AT_LIBTOOLIZE([--ltdl --install]) > LT_AT_ACLOCAL([-I libltdl/m4]) > LT_AT_AUTOCONF([--force]) >
libtool locking issue (was: [patch 00/19] @patch@ Queue)
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 04:45:14PM CEST: > Ralf Wildenhues wrote: > > > >Wow. I'm quite impressed! 8-) > > Amazing what one can do when locked in a room for a weekend with > nothing but an internet connection, and a fully stocked fridge! I thought arch can do without internet connection. Surely for me it would improve throughput to be without connection then.. ;-) > >>Looking forward to making the alpha release, > > > >Yep, me too. I've got a handful of own patches sitting here, which I'd > >like to push out before, but I'll probably agree to drop anything that > >will cost me more than a couple of days to push out. > > Sure thing. > > I'm afraid I don't understand the locking problem cited as the > last release blocking issue on the kicks-ass RoadMap, otherwise > I would have tackled that one too. I'm almost inclined to ignore it for the release. One example of it goes as follows: User uses LIBTOOL = /usr/bin/libtool in his Makefile. That `libtool' has need_locks=yes Now, the build tree is below a different mount point than /usr. This code in ltmain: | # Lock this critical section if it is needed | # We use this script file to make the link, it avoids creating a new file | if test "$need_locks" = yes; then |until $opt_dry_run || ln "$progpath" "$lockfile" 2>/dev/null; do | func_echo "Waiting for $lockfile to be removed" | sleep 2 |done | elif test "$need_locks" = warn; then will then deadlock. Or, instead of /usr/bin/libtool, LIBTOOL points inside some build tree of a different but related package (as I believe was in the bug report). Point is, it's actually nontrivial to assume any file name in the build tree to certainly be present, unless you also accept to create $OBJDIR in any case. And then you still need to be careful to do that, too. See the referenced mail for more thoughts about a solution. This issue is much less likely to actually hit anyone since the boilerplate patches are in place. Cheers, Ralf
Re: libtool locking issue (was: [patch 00/19] @patch@ Queue)
* Ralf Wildenhues wrote on Mon, Oct 10, 2005 at 05:10:21PM CEST:
>
> One example of it goes as follows: User uses
> LIBTOOL = /usr/bin/libtool
> in his Makefile. That `libtool' has
> need_locks=yes
> Now, the build tree is below a different mount point than /usr.
>
> This code in ltmain:
> |until $opt_dry_run || ln "$progpath" "$lockfile" 2>/dev/null; do
> | func_echo "Waiting for $lockfile to be removed"
> | sleep 2
> |done
> | elif test "$need_locks" = warn; then
>
> will then deadlock.
Quite some time ago, I started a test for this. Since compilers without
`-c -o' support were hard to come by before Peter Ekberg joined in, :-))
I started out building a simulator, a script that will not allow both
options. It's not perfect yet, in that it emulates all the possible
failures of those compilers (there are different incarnations with
subtly different behavior wrt. subdirs, IIRC).
Maybe it helps, so here it is, for reference, cheaply forward-ported to
current CVS HEAD. It needs fixing wrt. the LT_AT_BOOTSTRAP arguments
given.
Cheers,
Ralf
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.172
diff -u -r1.172 Makefile.am
--- Makefile.am 7 Oct 2005 08:52:10 - 1.172
+++ Makefile.am 10 Oct 2005 15:35:07 -
@@ -478,6 +478,7 @@
tests/link-order.at \
tests/convenience.at \
tests/early-libtool.at \
+ tests/lock.at \
tests/template.at
EXTRA_DIST += $(TESTSUITE) $(TESTSUITE_AT) tests/package.m4
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.25
diff -u -r1.25 testsuite.at
--- tests/testsuite.at 7 Oct 2005 08:52:10 - 1.25
+++ tests/testsuite.at 10 Oct 2005 15:35:07 -
@@ -143,6 +143,8 @@
m4_include([link-order.at])
# Ensure our continued support for old interfaces.
m4_include([old-m4-iface.at])
+# locking
+m4_include([lock.at])
# Torturing subdir-objects builds
m4_include([am-subdir.at])
# standalone libltdl compilation
--- /dev/null 2005-08-03 12:45:51.659987528 +0200
+++ tests/lock.at 2005-10-10 17:29:45.0 +0200
@@ -0,0 +1,222 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2005 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# Test libtool locking, simulate compiler that does not understand `-c -o'.
+
+# TODO: --disable-libtool-lock
+
+AT_SETUP([locking test])
+
+eval `$LIBTOOL --config | $EGREP '^(SED|Xsed)='`
+
+mkdir bin
+AT_DATA([bin/wrapper],
+[[#!/bin/sh
+realcc=`echo "$0" | sed 's%.*/%%'`
+eat=
+errmsg=${wrapper_c_o_fatal+", bailing out"}
+for arg0
+do
+ case $arg0 in
+ -c)
+for arg
+do
+ case $eat in
+ yes) eat=no;;
+ *)
+ case $1 in
+ -o)
+ eat=1
+ case $2 in
+ *.o | *.obj)
+ echo "bogus option: -o $2$errmsg." >&2
+ test -n "$wrapper_c_o_fatal" && exit 1
+ ;;
+ *)
+ set x "$@" -o "$2";
+ shift
+ ;;
+ esac
+ ;;
+ *)
+ set x "$@" "$1"
+ shift
+ ;;
+ esac
+ esac
+ shift
+done
+break
+;;
+ esac
+done
+exec "$realcc" ${1+"$@"}
+exit 1
+]])
+
+chmod +x bin/wrapper
+ln -s wrapper bin/echo
+AT_CHECK([bin/echo a -b -c bla -o foo bar -baz], 0, ignore)
+AT_CHECK([bin/echo a -b -c bla -o foo.o bar -baz], 0, ignore, ignore)
+AT_CHECK([bin/echo a -b -c bla -o foo.obj bar -baz], 0, ignore, ignore)
+AT_CHECK([bin/echo a -b bla -o foo.obj bar -baz], 0, ignore)
+AT_CHECK([wrapper_c_o_fatal=: bin/echo a -b -c bla -o foo bar -baz], 0, ignore)
+AT_CHECK([wrapper_c_o_fatal=: bin/echo a -b -c bla -o foo.o bar -baz], 1,
ignore, ignore)
+AT_CHECK([wrapper_c_o_fatal=: bin/echo a -b -c bla -o foo.obj bar -baz], 1,
ignore, ignore)
+AT_CHECK([wrapper_c_o_fa
Re: [patch 18/19] 300-gary-simplify-tests.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 05:23:17PM CEST: > Ralf Wildenhues wrote: > > > >Why not rather > > LT_AT_BOOTSTRAP([LIBTOOLIZE-ARGS], [AUTORECONF-ARGS], [CONFIGURE-ARGS]) > >? If you agree, please go ahead and commit a change to that extent. > >Rationale: I would like some tests to not have `--force', for example; > >also `--ltdl' would be necessary as per my other reject. > > Good call. I also needed to fix-up the removal of patch 287, so I've > changed this already :-) Yep, forgot that. Better to do a quick audit for all LT_AT_BOOTSTRAP uses.. > >The old-m4-iface.at change is fine. If you're bored, you could also > >fix Makefile.am, testsuite.at to point $macrodir to the installed > >directory for `installcheck'.. > > Nice catch! I've added that to patch 280 (where macrodir was introduced). Erm, 280 was committed already on 2005-09-30, right? So just commit the change in a new patch if you like. Cheers, Ralf
FYI: stresstest -no-undefined nitfix
I have applied the following trivial bugfix to CVS HEAD (every $host_os which sets allow_undefined_flag=unsupported needs this), in order to facilitate further BeOS testing and save Christian from having to report yet another bug in the testsuite. :) Cheers, Ralf * tests/stresstest.at [ aix3, beos, os2 ]: Always use `-no-undefined'. Index: tests/stresstest.at === RCS file: /cvsroot/libtool/libtool/tests/stresstest.at,v retrieving revision 1.6 diff -u -r1.6 stresstest.at --- tests/stresstest.at 13 Sep 2005 07:28:14 - 1.6 +++ tests/stresstest.at 10 Oct 2005 16:22:52 - @@ -171,8 +171,10 @@ AT_CHECK([$LIBTOOL --mode=compile $CC $CFLAGS -c dlself.c -o sub3/dlself.lo],[0],[ignore],[ignore]) case $host_os in - cygwin* | mingw* | pw32*) undef_opts=-no-undefined ;; - *)undef_opts='"" -no-undefined' ;; + aix3* | beos* | cygwin* | mingw* | os2* | pw32*) +undef_opts=-no-undefined ;; + *) +undef_opts='"" -no-undefined' ;; esac for l1 in $undef_opts
Re: FYI: stresstest -no-undefined nitfix
* Ralf Wildenhues wrote on Mon, Oct 10, 2005 at 06:26:04PM CEST: > I have applied the following trivial bugfix to CVS HEAD > (every $host_os which sets allow_undefined_flag=unsupported needs this), D'oh. Any reason against applying this instead? (getting the "trivial" ones wrong should teach me to ask for approval..) Cheers, Ralf * tests/stresstest.at: Use `allow_undefined_flag' instead of host_os setting. Index: tests/stresstest.at === RCS file: /cvsroot/libtool/libtool/tests/stresstest.at,v retrieving revision 1.7 diff -u -r1.7 stresstest.at --- tests/stresstest.at 10 Oct 2005 16:25:09 - 1.7 +++ tests/stresstest.at 10 Oct 2005 18:50:26 - @@ -23,7 +23,7 @@ AT_BANNER([Libtool stress test.]) AT_SETUP([Link option thorough search test]) -eval `$LIBTOOL --config | $EGREP '^(CC|objdir)='` +eval `$LIBTOOL --config | $EGREP '^(CC|objdir|allow_undefined_flag)='` mkdir sub sub2 sub3 2>/dev/null @@ -170,11 +170,9 @@ AT_CHECK([$LIBTOOL --mode=compile $CC $CFLAGS -c main.c],[0],[ignore],[ignore]) AT_CHECK([$LIBTOOL --mode=compile $CC $CFLAGS -c dlself.c -o sub3/dlself.lo],[0],[ignore],[ignore]) -case $host_os in - aix3* | beos* | cygwin* | mingw* | os2* | pw32*) -undef_opts=-no-undefined ;; - *) -undef_opts='"" -no-undefined' ;; +case $allow_undefined_flag in + unsupported) undef_opts=-no-undefined ;; + *) undef_opts='"" -no-undefined' ;; esac for l1 in $undef_opts
Re: FYI: centralise INCLTDL [291]
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 07:21:39PM CEST:
>
> Applied to HEAD.
Gah, it breaks mdemo. mdemo/configure.ac does not invoke LT_WITH_LTDL
_at all_. Looking at branch-1-5, I guess we have to support this
mode, too. :-/
Can you look into fixing this?
Cheers,
Ralf
> from Gary V. Vaughan <[EMAIL PROTECTED]>
>
> * libltdl/m4/ltdl.m4 (LTDL_CONVENIENCE, LTDL_INSTALLABLE): Remove
> AC_SUBST of LIBLTDL, LTDLINCL, and all mention of INCLTDL.
> (LT_WITH_LTDL): Due to order constraints between LTDL_CONVENIENCE,
> LTDL_INSTALLABLE, LT_WITH_LTDL & LTDL_INIT, we can safely AC_SUBST
> LIBLTDL and LTDLINCL here. Also, remember to synch INCLTDL.
>
> --- orig/libltdl/m4/ltdl.m4
> +++ mod/libltdl/m4/ltdl.m4
> @@ -63,13 +63,6 @@
> esac
>LIBLTDL='${top_builddir}'"${lt_ltdl_dir+/$lt_ltdl_dir}/libltdlc.la"
>LTDLINCL='-I${top_srcdir}'"${lt_ltdl_dir+/$lt_ltdl_dir}"
> -
> -AC_SUBST([LIBLTDL])
> -AC_SUBST([LTDLINCL])
> -
> -# For backwards non-gettext consistent compatibility...
> -INCLTDL="$LTDLINCL"
> -AC_SUBST([INCLTDL])
>])# LTDL_CONVENIENCE
>
># AC_LIBLTDL_CONVENIENCE accepted a directory argument in older libtools,
> @@ -119,13 +112,6 @@
> LIBLTDL="-lltdl"
> LTDLINCL=
>fi
> -
> -AC_SUBST([LIBLTDL])
> -AC_SUBST([LTDLINCL])
> -
> -# For backwards non-gettext consistent compatibility...
> -INCLTDL="$LTDLINCL"
> -AC_SUBST([INCLTDL])
>])# LTDL_INSTALLABLE
>
># AC_LIBLTDL_INSTALLABLE accepted a directory argument in older libtools,
> @@ -198,6 +184,11 @@
> [],
>[LTDL_INIT
>AC_DEFUN([LTDL_INIT], [])])
> +
> +AC_SUBST([LIBLTDL])
> +AC_SUBST([LTDLINCL])
> +dnl For backwards non-gettext consistent compatibility...
> +AC_SUBST([INCLTDL], ["$LTDLINCL"])
>])# LT_WITH_LTDL
>
># Old name:
Re: FYI: stresstest -no-undefined nitfix
Hi Gary, * Gary V. Vaughan wrote on Tue, Oct 11, 2005 at 12:32:12AM CEST: > Ralf Wildenhues wrote: > > * Ralf Wildenhues wrote on Mon, Oct 10, 2005 at 06:26:04PM CEST: > > > >>I have applied the following trivial bugfix to CVS HEAD > >>(every $host_os which sets allow_undefined_flag=unsupported needs this), > > > > D'oh. Any reason against applying this instead? > > Nope, please go right ahead! Done. Thanks, Ralf > > * tests/stresstest.at: Use `allow_undefined_flag' instead of > > host_os setting.
Re: FYI: centralise INCLTDL [291]
Hi Gary, * Gary V. Vaughan wrote on Tue, Oct 11, 2005 at 12:29:26AM CEST: > Ralf Wildenhues wrote: > > * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 07:21:39PM CEST: > > > >>Applied to HEAD. > > > > Gah, it breaks mdemo. mdemo/configure.ac does not invoke LT_WITH_LTDL > > _at all_. Looking at branch-1-5, I guess we have to support this > > mode, too. :-/ > > > > Can you look into fixing this? > > No need. *everything* passes when all my patches are applied. It's > only because we're tackling them out of order that the tree is a little > inconsistent right now. Feel free to back it out, and I'll reapply > later when the other patches go in... > > If you have a particular host that fails with the whole stack applied on > the other hand, I'd like to fix that... Fails also mdemo-make tests with all patches applied in order (GNU/Linux, bootstrapped with 2.59/1.9.2, no libobj patches applied): [...] | gcc -DPACKAGE_NAME=\"mdemo\" -DPACKAGE_TARNAME=\"mdemo\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"mdemo\ 1.0\" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DPACKAGE=\"mdemo\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MATH_H=1 -I. -I/tmp/libtool/tests/mdemo -I/tmp/libtool/tests/mdemo/../..-g -O2 -c /tmp/libtool/tests/mdemo/main.c | /bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -o mdemo -export-dynamic main.o ./../../libltdl/libltdlc.la libsub.la "-dlopen" self "-dlopen" foo1.la "-dlopen" libfoo2.la | libtool: link: rm -f .libs/mdemo.nm .libs/mdemo.nmS .libs/mdemo.nmT | libtool: link: creating .libs/mdemoS.c | libtool: link: generating symbol list for `mdemo' | libtool: link: extracting global C symbols from `main.o' | libtool: link: (cd .libs && gcc -g -O2 -c -fno-builtin "mdemoS.c") | libtool: link: rm -f ".libs/mdemoS.c" ".libs/mdemo.nm" ".libs/mdemo.nmS" ".libs/mdemo.nmT" | libtool: link: gcc -g -O2 -o .libs/mdemo main.o .libs/mdemoS.o -Wl,--export-dynamic /tmp/build/libltdl/.libs/dlopen.a ./../../libltdl/.libs/libltdlc.a -ldl ./.libs/libsub.so -Wl,-rpath -Wl,/tmp/build/_inst/lib | main.o(.text+0x420): In function `main': | /tmp/libtool/tests/mdemo/main.c:180: undefined reference to `lt_preloaded_symbols' | collect2: ld returned 1 exit status | make: *** [mdemo] Error 1 To reproduce, I guess all you'll have to do is uninstall any ltdl.h from CVS HEAD. I suggest reverting your change and applying my suggested, pretty trivial patch, instead. Do you agree? Cheers, Ralf
Re: [patch 05/19] 288-gary-ltdl-nonrecursive-tests.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:29PM CEST: > Makefile.am |1 > tests/nonrecursive.at | 115 > ++ > tests/testsuite.at|2 > 3 files changed, 118 insertions(+) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * tests/subdirectory.at: New tests for libltdl as a subdirectory, > configured and compiled from the toplevel project. > * tests/testsuite.at: Use it. > * Makefile.am (TESTSUITE_AT): Depend on it. See nits below, and this one: all of them FAIL with 2.59/1.9.6 (without libobjdir fixes): [...] | nonrecursive.at:66: $AUTORECONF --force --verbose --install | stderr: | autoreconf: Entering directory `.' | autoreconf: configure.ac: not using Gettext | autoreconf: running: aclocal --force -I libltdl/m4 | autoreconf: configure.ac: tracing | autoreconf: configure.ac: not using Libtool | autoreconf: running: autoconf --force | autoreconf: running: autoheader --force | autoreconf: running: automake --add-missing --copy --force-missing | configure.ac: installing `libltdl/config/install-sh' | configure.ac: installing `libltdl/config/missing' | configure.ac:8: installing `libltdl/config/config.guess' | configure.ac:8: installing `libltdl/config/config.sub' | Makefile.am: installing `libltdl/config/compile' | configure.ac:11: required file `./lt__dirent.c' not found | configure.ac:11: required file `./argz.c' not found | configure.ac:11: required file `./lt__strl.c' not found | Makefile.am: installing `libltdl/config/depcomp' | autoreconf: automake failed with exit status: 1 Can you make them SKIP in this case, so we don't get oodles of bogus bug reports? I'm not _quite_ sure how to do this nicely. Reinstating your extra test for woring LIBOBJDIR support won't help: autotest tests should be independent of each other, and runnable on their own. Maybe just make a macro that wraps the `automake' call, saves its output and checks for error containing `lt__dirent' specifically, in order to decide whether to SKIP? More below. Cheers, Ralf > Index: libtool--devo--1.0/Makefile.am > === > --- libtool--devo--1.0.orig/Makefile.am > +++ libtool--devo--1.0/Makefile.am > @@ -360,6 +360,7 @@ TESTSUITE_AT = tests/testsuite.at \ > tests/duplicate_members.at \ > tests/inherited_flags.at \ > tests/libtoolize.at \ > + tests/nonrecursive.at \ > tests/old-m4-iface.at \ > tests/standalone.at \ > tests/deplibs-ident.at \ > Index: libtool--devo--1.0/tests/nonrecursive.at > === > --- /dev/null > +++ libtool--devo--1.0/tests/nonrecursive.at > @@ -0,0 +1,115 @@ > +# Hand crafted tests for GNU Libtool. -*- Autotest > -*- > +# Copyright 2005 Free Software Foundation, Inc. > + > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2, or (at your option) > +# any later version. > + > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > + > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA > +# 02111-1307, USA. > + > + > +AT_BANNER([Nonrecursive Automake Libltdl.]) > + > +# _LTDL_SETUP The naming is unfortunate. As all the tests share an m4 macro name space, and you actually use _LTDL_SETUP in several othere tests for a different purpose, please rename all of them. Maybe m4_undefine at the end of the test would be ok as well, but then I believe you wanted to share some macros. > +# --- > +m4_define([_LTDL_SETUP], > +[AT_DATA([configure.ac], > +[[AC_INIT([subdirectory-demo], ]AT_PACKAGE_VERSION[, ]AT_PACKAGE_BUGREPORT[) > +LT_CONFIG_LTDL_DIR([libltdl], [nonrecursive]) > +AC_CONFIG_AUX_DIR([libltdl/config]) > +AC_CONFIG_MACRO_DIR([libltdl/m4]) > +AC_CONFIG_LIBOBJ_DIR([libltdl]) Urgs. In large packages, these three settings are going to be a major pain in the long run. I'm not saying you need to change them here, this issue isn't a Libtool problem rather than an Autoconf/Automake one, but it'd be good if people could change all three of these and things would still work somehow. (Just thinking out loud; nothing we'll want to worry about before 2.0.) > +AM_PROG_CC_C_O Why do you need this? Is it only for Automake backwards compatibility? If so, then I recommend adding AC_PROG_CC before as well. > +AM_INIT_AUTOMAKE(
Re: [patch 05/19] 288-gary-ltdl-nonrecursive-tests.diff Queue
Hi Gary, Just responding to some issues for now: * Gary V. Vaughan wrote on Tue, Oct 11, 2005 at 11:53:17AM CEST: > Ralf Wildenhues wrote: > > >* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:29PM CEST: > >>* tests/subdirectory.at: New tests for libltdl as a subdirectory, > >>configured and compiled from the toplevel project. > >>* tests/testsuite.at: Use it. > >>* Makefile.am (TESTSUITE_AT): Depend on it. > > > >See nits below, and this one: all of them FAIL with 2.59/1.9.6 (without > >libobjdir fixes): *snip* > >>+# _LTDL_SETUP > > > >The naming is unfortunate. As all the tests share an m4 macro name > >space, and you actually use _LTDL_SETUP in several othere tests for a > >different purpose, please rename all of them. > > No need, it's fine. The name is quoted in the m4_define exactly so that > we can do this sort of thing. What is the point of renaming? > > >Maybe m4_undefine at the > >end of the test would be ok as well, but then I believe you wanted to > >share some macros. > > Okay. That's less intrusive. I'll pushdef/popdef the definition then, > which is the cleanest way to stop it leaking out into other tests. The pushdef/popdef is with me, thank you. > >>+AM_PROG_CC_C_O > > > >Why do you need this? Is it only for Automake backwards compatibility? > > subdir-objects requires it. > > >If so, then I recommend adding AC_PROG_CC before as well. > > Seems like overkill to me... Belt and braces? Yes. Quoting automake/ChangeLog: | 2004-09-10 Alexandre Duret-Lutz <[EMAIL PROTECTED]> | | * m4/minuso.m4 (AM_PROG_CC_C_O): Make sure AC_PROG_CC is never | called after this macro. My request is for user education. > $ fgrep -l AM_PROG_CC_C_O /usr/share/aclocal*/*.m4 *snip* But thanks anyway for the history analysis. :-) > >>+AM_INIT_AUTOMAKE([foreign subdir-objects]) > > > >I believe you should have AM_INIT_AUTOMAKE before AM_PROG_CC_C_O. > >After all, AM_INIT_AUTOMAKE should be the first automake macro called. > > Again, I'm not sure about this reasoning :-) AM_PROG_CC_C_O is designed > to be a wrapper for AC_PROG_CC, No, it's *documented* to be necessary in some cases. The fact that it AC_REQUIREs AC_PROG_CC is an *implementation detail*, the user _should_ use both. Hey, persuade the Automake maintainer to document "calling `AM_PROG_CC_C_O' makes previous calling of `AC_PROG_CC' obsolete" and I will change my mind. > and surely AC_PROG_CC should come before AM_INIT_AUTOMAKE? Not at all, why? INIT sounds like: do this first. Right? Sounds right to me. Everything that has to become before this _needs_ to be documented very explicitly. Quoting automake.info (Complete): |The first step is to update your `configure.ac' to include the | commands that `automake' needs. The way to do this is to add an | `AM_INIT_AUTOMAKE' call just after `AC_INIT': This sounds very different to me. > I don't want to change this, but if you are firm, and > it still works then I can be persuaded... Yes, I am (unless you persuade the Automake maintainer to change the documentation). For education purposes. Cheers, Ralf
Re: FYI: centralise INCLTDL [291]
Hi Gary,
* Gary V. Vaughan wrote on Tue, Oct 11, 2005 at 10:22:02AM CEST:
> Ralf Wildenhues wrote:
>
> >I suggest reverting your change and applying my suggested, pretty
> >trivial patch, instead. Do you agree?
>
> Yes.
Good. Reverted your patch and applied mine, both shown below.
> I'll have a poke around and see if I can make a working version
> of my patch later, as I do think it is nicer to consolidate the whole
> thing if possible.
OK. I would not see this as very important, though.
Cheers,
Ralf
* libltdl/m4/ltdl.m4 (LTDL_CONVENIENCE, LTDL_INSTALLABLE)
(LT_WITH_LTDL): Revert Gary's 2005-10-10 patch.
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.12
diff -u -r1.12 ltdl.m4
--- libltdl/m4/ltdl.m4 10 Oct 2005 17:28:58 - 1.12
+++ libltdl/m4/ltdl.m4 11 Oct 2005 11:24:15 -
@@ -63,6 +63,13 @@
esac
LIBLTDL='${top_builddir}'"${lt_ltdl_dir+/$lt_ltdl_dir}/libltdlc.la"
LTDLINCL='-I${top_srcdir}'"${lt_ltdl_dir+/$lt_ltdl_dir}"
+
+AC_SUBST([LIBLTDL])
+AC_SUBST([LTDLINCL])
+
+# For backwards non-gettext consistent compatibility...
+INCLTDL="$LTDLINCL"
+AC_SUBST([INCLTDL])
])# LTDL_CONVENIENCE
# AC_LIBLTDL_CONVENIENCE accepted a directory argument in older libtools,
@@ -112,6 +119,13 @@
LIBLTDL="-lltdl"
LTDLINCL=
fi
+
+AC_SUBST([LIBLTDL])
+AC_SUBST([LTDLINCL])
+
+# For backwards non-gettext consistent compatibility...
+INCLTDL="$LTDLINCL"
+AC_SUBST([INCLTDL])
])# LTDL_INSTALLABLE
# AC_LIBLTDL_INSTALLABLE accepted a directory argument in older libtools,
@@ -184,11 +198,6 @@
[],
[LTDL_INIT
AC_DEFUN([LTDL_INIT], [])])
-
-AC_SUBST([LIBLTDL])
-AC_SUBST([LTDLINCL])
-dnl For backwards non-gettext consistent compatibility...
-AC_SUBST([INCLTDL], ["$LTDLINCL"])
])# LT_WITH_LTDL
# Old name:
*snip*
* libltdl/m4/ltdl.m4 (LT_WITH_LTDL): Also set INCLTDL.
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.13
diff -u -r1.13 ltdl.m4
--- libltdl/m4/ltdl.m4 11 Oct 2005 11:25:08 - 1.13
+++ libltdl/m4/ltdl.m4 11 Oct 2005 11:27:16 -
@@ -185,6 +185,7 @@
[Define this if a modern libltdl is already installed])
LIBLTDL=-lltdl
LTDLINCL=
+ INCLTDL=
fi
# Report our decision...
Re: [patch 02/19] 284-gary-report-macro-files-for-aclocal.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:26PM CEST: > libtoolize.m4sh | 24 ++-- > 1 files changed, 18 insertions(+), 6 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Copying just libtool.m4 for hand maintained > aclocal.m4 doesn't work. List all required files in that case. > Also, list the additional files required when using libltdl. > Reported by Patrick Welche <[EMAIL PROTECTED]>. OK with one nit, see below. I'm also afraid we may have to undo part of this when we're through with the `make dist' problem. But that will be dealt with in due course then. Let's get the stack worked through first. Cheers, Ralf > Index: libtool--devo--1.0/libtoolize.m4sh > === > --- libtool--devo--1.0.orig/libtoolize.m4sh > +++ libtool--devo--1.0/libtoolize.m4sh > @@ -995,17 +995,29 @@ func_nonemptydir_p () > > func_copy_some_files "$pkgmacro_files" "$aclocaldir" \ >"$m4dir" func_serial_update > - else > - $opt_quiet || func_echo "You should add the contents of > \`$aclocaldir/libtool.m4' to \`aclocal.m4'." >fi > ># Suggest modern idioms for storing autoconf macros: >$opt_quiet || \ > -if test -z "$macrodir$ltdldir" && $seen_autoconf; then > - if test x"$m4dir" = x.; then > -func_echo "add \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac to > store autoconf macros" > +if $seen_autoconf; then > + if test -z "$macrodir$ltdldir"; then > + if test x"$m4dir" = x.; then > + func_echo "add \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac and > rerun libtoolize," > + func_echo "to keep the correct libtool macros in-tree." > + else > + func_echo "consider adding \`AC_CONFIG_MACRO_DIR([$m4dir])'to > $configure.ac," > + func_echo "and rerunning libtoolize." > + fi >else > -func_echo "consider adding \`AC_CONFIG_MACRO_DIR([$m4dir])'to > $configure.ac" > +func_echo "You should add the contents of the following files to > \`aclocal.m4':" > + for need in libtool.m4 ltoptions.m4 ltversion.m4 ltsugar.m4; do > + func_echo "\`$aclocaldir/$need'" > + done > + if $seen_ltdl || $opt_ltdl; then > + for need in argz.m4 ltdl.m4; do > + func_echo "\`$aclocaldir/$need'" > + done What I meant in the other thread we were discussing this: add right here something like this: func_echo "or instead follow the advice about \`AC_CONFIG_MACRO_DIR' below." since the macros exist below $ltdldir/m4 anyway.. Clear now? > + fi >fi > fi
Re: [patch 03/19] 285-gary-diagnose-missing-LT_WITH_LTDL.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:27PM CEST:
> libtoolize.m4sh | 91
>
> 1 files changed, 46 insertions(+), 45 deletions(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libtoolize.m4sh: Move the consistency checks...
> (func_check_macros): ...into here. Also suggest LT_WITH_LTDL if
> appropriate.
Not quite like this. Comments below.
Cheers,
Ralf
> Index: libtool--devo--1.0/libtoolize.m4sh
> ===
> --- libtool--devo--1.0.orig/libtoolize.m4sh
> +++ libtool--devo--1.0/libtoolize.m4sh
> @@ -795,16 +795,55 @@ func_check_macros ()
> {
> $opt_debug
>
> -$seen_autoconf \
> - || return
> +$seen_autoconf || return
> +
> +# Suggest modern idioms for storing autoconf macros:
> +if test -z "$macrodir$ltdldir"; then
> + if test x"$m4dir" = x.; then
> +func_echo "add \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac and
> rerun libtoolize,"
> +func_echo "to keep the correct libtool macros in-tree."
> + else
> +func_echo "consider adding \`AC_CONFIG_MACRO_DIR([$m4dir])'to
> $configure.ac,"
> +func_echo "and rerunning libtoolize."
> + fi
> +elif test -z "$m4dir"; then
> + func_echo "You should add the contents of the following files to
> \`aclocal.m4':"
> + for need in libtool.m4 ltoptions.m4 ltversion.m4 ltsugar.m4; do
> +func_echo "\`$aclocaldir/$need'"
> + done
> + if $seen_ltdl || $opt_ltdl; then
> +for need in argz.m4 ltdl.m4; do
> + func_echo "\`$aclocaldir/$need'"
> +done
Don't forget to move my added comment, in case you agree with it (in
response to patch 284).
> + fi
> +fi
> +
> +$seen_libtool ||
> + func_echo "remember to add \`LT_INIT' to $configure_ac."
>
> # Don't trace for this, we're just checking the user didn't invoke it
> # directly from configure.ac.
> -$SED 's,[d]nl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB \
> - && func_echo "\`AC_PROG_RANLIB' is rendered obsolete by \`LT_INIT'"
> +$SED 's,[d]nl .*$,,; s,# .*$,,' "$configure_ac" | grep AC_PROG_RANLIB &&
> + func_echo "\`AC_PROG_RANLIB' is rendered obsolete by \`LT_INIT'"
Now that I see this: Please remove these two lines, or make them as
little intrusive as branch-1-5 was: grepped for '^AC_PROG_RANLIB'.
Rationale: a `libtoolize' that'll bug me every time because of
m4_if([I_USE_LIBTOOL],
[AM_PROG_LIBTOOL],
[AC_PROG_RANLIB])
will make me not listen to it. Besides, I *could* be using libltdl
as subpackage (and thus `libtoolize --ltdl') but not wanting to use
libtool in the parent package.
So, the warning above to add LT_INIT is also slightly bogus.
> +
> +$opt_ltdl && {
> +
> + # Suggest using LT_WITH_LTDL if appropriate:
> + $seen_ltdl ||
> +func_echo "remember to add \`LT_WITH_LTDL' to $configure_ac"
Erm, can we make this `consider using' instead of `remember to add'?
LT_WITH_LTDL is _not_ necessary.
> +
> + # Remind the user to call LT_CONFIG_LTDL_DIR:
> + test -n "$ac_ltdldir" || \
> +func_echo "remember to add \`LT_CONFIG_LTDL_DIR([[$ltdldir]])' to
> \`$configure_ac'"
> +
> + # Offer some suggestions for avoiding duplicate files in a project
> + # that uses libltdl:
> + test "$ltdldir/config" = "$auxdir" || \
> +func_echo "consider using \`AC_CONFIG_AUX_DIR([[$ltdldir/config]])'
> in $configure_ac"
> + test "$ltdldir/m4" = "$m4dir" || \
> +func_echo "consider using \`AC_CONFIG_MACRO_DIR([[$ltdldir/m4]])' in
> $configure_ac"
>
> -$seen_libtool \
> - || func_echo "Remember to add \`LT_INIT' to \`$configure_ac'."
> +}
>
> # FIXME: Ensure ltmain.sh, libtool.m4 and ltdl.m4 are from the same
> release
> }
> @@ -942,7 +981,6 @@ func_nonemptydir_p ()
>glob_exclude_pkgaux_files='config.guess|config.sub|install-sh|ltmain.sh'
>
>func_scan_files
> - $opt_quiet || func_check_macros
>
># Copy all the files from installed libltdl to this project, if the
># user specified `--ltdl'.
> @@ -997,44 +1035,7 @@ func_nonemptydir_p ()
>"$m4dir" func_serial_update
>fi
>
> - # Suggest modern idioms for storing autoconf macros:
> - $opt_quiet || \
> -if $seen_autoconf; then
> - if test -z "$macrodir$ltdldir"; then
> - if test x"$m4dir" = x.; then
> - func_echo "add \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac and
> rerun libtoolize,"
> - func_echo "to keep the correct libtool macros in-tree."
> - else
> - func_echo "consider adding \`AC_CONFIG_MACRO_DIR([$m4dir])'to
> $configure.ac,"
> - func_echo "and rerunning libtoolize."
> - fi
> - else
> -func_echo "You should add the contents of the following files to
> \`aclocal.m4':"
> - for need in li
subproject.at distcheck failure
The first three subproject.at tests fail within `make distcheck': - during the `check' (not installcheck!) phase within distcheck, the source tree is readonly, - libtoolize either symlinks or copies with kept permissions the ltdl files (use of tar!), - `autoreconf --force', seeing the sub/ltdl subproject, enters the sub/ltdl directory, in there, aclocal tries to write sub/ltdl/aclocal.m4 (without removing it first). If we remove the `--force', still autoconf fails, because it tries to write to `sub/ltdl/configure'. I'm not quite sure about the best way to handle this. We could replace autoreconf with calling aclocal, automake, and autoconf by hand to prevent recursing. Proposed patch below ok? Note that the config.h.in workaround is necessary only until Gary's fix to this end is applied to ltdl.m4. Maybe autoreconf should have an option _not_ to enter subprojects? Note that this issue is different from the one Charles reported; there are no readonly trees involved in that one. We'r also reminded that symlinked ltdl/ is a bad idea, but this particular issue is not limited to symlinking. Cheers, Ralf * tests/testsuite.at (LT_AT_AUTOMAKE): New macro. * tests/subproject.at: Use it. Do not call `autoreconf' in tests, since it will try to reconfigure `sub/ltdl', which breaks `make check' during `distcheck' because of a readonly source tree. Index: tests/testsuite.at === RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v retrieving revision 1.25 diff -u -r1.25 testsuite.at --- tests/testsuite.at 7 Oct 2005 08:52:10 - 1.25 +++ tests/testsuite.at 11 Oct 2005 16:03:16 - @@ -69,6 +69,13 @@ ]) +# LT_AT_AUTOMAKE([OPTIONS]) +# -- +m4_define([LT_AT_AUTOMAKE], +[AT_CHECK([$AUTOMAKE $1], [0], [ignore], [ignore]) +]) + + # LT_AT_AUTORECONF([OPTIONS]) # -- m4_define([LT_AT_AUTORECONF], Index: tests/subproject.at === RCS file: /cvsroot/libtool/libtool/tests/subproject.at,v retrieving revision 1.2 diff -u -r1.2 subproject.at --- tests/subproject.at 5 Oct 2005 16:45:09 - 1.2 +++ tests/subproject.at 11 Oct 2005 16:03:16 - @@ -51,8 +51,11 @@ AT_SETUP([compiling softlinked libltdl]) _LTDL_SETUP +touch config.h.in LT_AT_LIBTOOLIZE([--ltdl]) -LT_AT_AUTORECONF([--force --verbose --install]) +LT_AT_ACLOCAL([-I sub/ltdl/m4]) +LT_AT_AUTOMAKE([--add-missing --copy]) +LT_AT_AUTOCONF LT_AT_CONFIGURE LT_AT_MAKE @@ -68,8 +71,11 @@ AT_SETUP([compiling copied libltdl]) _LTDL_SETUP +touch config.h.in LT_AT_LIBTOOLIZE([--copy --ltdl]) -LT_AT_AUTORECONF([--force --verbose --install]) +LT_AT_ACLOCAL([-I sub/ltdl/m4]) +LT_AT_AUTOMAKE([--add-missing --copy]) +LT_AT_AUTOCONF LT_AT_CONFIGURE LT_AT_MAKE @@ -87,8 +93,11 @@ prefix=`pwd`/_inst _LTDL_SETUP +touch config.h.in LT_AT_LIBTOOLIZE([--copy --ltdl]) -LT_AT_AUTORECONF([--force --verbose --install]) +LT_AT_ACLOCAL([-I sub/ltdl/m4]) +LT_AT_AUTOMAKE([--add-missing --copy]) +LT_AT_AUTOCONF LT_AT_CONFIGURE([--enable-ltdl-install --prefix=$prefix]) LT_AT_MAKE([all install])
Re: [patch 14/19] 298-gary-document-libltdl-build-modes.diff Queue
Forgot one thing, sorry:
* Ralf Wildenhues wrote on Mon, Oct 10, 2005 at 03:54:12PM CEST:
>
> * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:38PM CEST:
> > doc/libtool.texi | 92
> > +--
> > 1 files changed, 90 insertions(+), 2 deletions(-)
>
> OK when nits and comments below addressed and requirements committed. :-)
> > Index: libtool--devo--1.0/doc/libtool.texi
> > ===
> > --- libtool--devo--1.0.orig/doc/libtool.texi
> > +++ libtool--devo--1.0/doc/libtool.texi
> > @@ -4186,10 +4186,98 @@ or against both a local convenience libr
> > is bad. Ensuring that only one copy of the libltdl sources are linked
> > into any program is left as an exercise for the reader.
> >
> > [EMAIL PROTECTED] LT_CONFIG_LTDL_DIR (@var{DIRECTORY})
> > [EMAIL PROTECTED] LT_CONFIG_LTDL_DIR (@var{DIRECTORY}. @var{LTDL-MODE})
In order for the `libtoolize' magic to work, LTDL-MODE needs to be both
an m4 literal as well as a greppable literal, i.e., not-a-macro.
I firmly believe autotools should document each of these thingies (there
are a few of these, e.g. in connection with `autoreconf'; I'll write bug
reports when bored..).
Cheers,
Ralf
Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:28PM CEST:
> Another step towards fixing LT_WITH_LTDL. Here we add an optional mode
> argument to libtoolize so that the user can tell libtoolize whether she
> is going to subconfigure libltdl as always, or use either a non-recursive
> automake (like libtool itself), or a recursive automake with a top-level
> configure. This patch *doesn't* attempt to clean up the m4 macros.
>
> Incidentally, this also removes the troublesome '## %%% BEGIN' magic from
> Makefile.am.
Very nice patch! But it mixes up two things, and at that quite heavily:
Do you want the (non)recursive/subproject info as argument to
LT_WITH_LTDL
or
LT_CONFIG_LTDL_DIR
or possibly both? Please redo `libtoolize' output based on the answer
of this (I did not finishing testing, but will do again after this is
fixed).
I have found more nits, see inline. Also, please remember:
- adjust doc plus makefiles for whatever you agree on wrt. *_LTLIBRARIES
DEFS, AM_CPPFLAGS, AM_CFLAGS: `+=' vs `='.
And please actually do the commit only together with the followup
patches needed to implement the functionality, so CVS HEAD is not in
broken state for long. Thank you.
Cheers,
Ralf
> Makefile.am | 122 ++---
> NEWS |4 +
> bootstrap|5 +
> doc/libtool.texi | 46 +
> libltdl/Makefile.inc | 137
> +++
> libltdl/m4/ltdl.m4 |8 ++
> libtoolize.m4sh | 71 --
> 7 files changed, 269 insertions(+), 124 deletions(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libltdl/Makefile.inc: New file, factored out of Makefile.am for
> use in non-recursive libltdl installations.
> * Makefile.am: include it.
> (libltdl/Makefile.am): Adjust to build from the new
> libltdl/Makefile.inc.
> * bootstrap: Adjust.
> * doc/libtool.texi (Invoking libtoolize): Document the new modes
> and libtoolize option to select them.
> * libtoolize.m4sh: Parse new options, --nonrecursive, --recursive
> and --subproject. Install the appropriate files with --ltdl
> according to the selected mode.
> (func_scan_files): If --subproject, --recursive or --nonrecursive
> options were not given, use the value from LT_CONFIG_LTDL_DIR; if
> a mode was given, and there is also an argument to
> LT_CONFIG_LTDL_DIR, ensure they are the same.
> * NEWS: Updated.
First nit: the patch changes (a comment in) libltdl/m4/ltdl.m4, but the
log entry does not mention this.
*big snip*
> Index: libtool--devo--1.0/doc/libtool.texi
> ===
> --- libtool--devo--1.0.orig/doc/libtool.texi
> +++ libtool--devo--1.0/doc/libtool.texi
> @@ -2249,11 +2249,57 @@ also specify a subdirectory name here if
> for example. If @command{libtoolize} can't determine the target
> directory, @samp{libltdl} is used as the default.
>
> [EMAIL PROTECTED] --nonrecursive
> +If passed in conjunction with @option{--ltdl}, this option will cause
> +the @command{libtoolize} installed @samp{libltdl} to be set up for use
Hypen between `libtoolize' and `installed'? Alternatively:
.. the libltdl installed by libtoolize..?
> +with a non-recursive @command{automake} build. To make use of it, you
> +will need to add the following to the @file{Makefile.am} of the parent
> +project (adjusted to include the file from whatever directory you
> +installed libltdl to):
> +
> [EMAIL PROTECTED]
> +include libltdl/Makefile.inc
> [EMAIL PROTECTED] example
Now, how's that gonna work if the user uses a name different from
`libltdl/' as subdir? The paths in `libltdl/Makefile.inc' are pretty
hardcoded to start with `libltdl/'!
No need to change the implementation IMHO, but it may be good to adjust
above paragraph to match the limitation to firmly state: if you use
nonrecursive, that subdir better be named `libltdl' and nothing else!
> +
> @item --quiet
> @itemx -q
> Work silently. @samp{libtoolize --quiet} is used by @sc{gnu} Automake
> to add libtool files to your package if necessary.
>
> [EMAIL PROTECTED] --recursive
> +If passed in conjunction with @option{--ltdl}, this option will cause
> +the @command{libtoolize} installed @samp{libltd} to be set up for use
> +with a recursive @command{automake} build. To make use of it, you
> +will need to adjust the parent project's @file{configure.ac}:
> +
> [EMAIL PROTECTED]
> +AC_CONFIG_FILES([libltdl/Makefile])
> [EMAIL PROTECTED] example
> +
> [EMAIL PROTECTED]
> +and @file{Makefile.am}:
> +
> [EMAIL PROTECTED]
> +SUBDIRS += libltdl
> [EMAIL PROTECTED] example
> +
> [EMAIL PROTECTED] --subproject
> +If passed in conjunction with @option{--ltdl}, this option will cause
> +the @command{libtoolize} installed @samp{libltd} to be set up for
s/
FYI: subproject.at distcheck failure
Hi Gary, * Gary V. Vaughan wrote on Tue, Oct 11, 2005 at 06:27:33PM CEST: > Ralf Wildenhues wrote: > >The first three subproject.at tests fail within `make distcheck': *snip* > > AARGH! Yep, my thoughts exactly, when I first hit this. > >I'm not quite sure about the best way to handle this. We could > >replace autoreconf with calling aclocal, automake, and autoconf by > >hand to prevent recursing. Proposed patch below ok? > > Sure. Looks good to me. Thanks. Installed. Cheers, Ralf > >* tests/testsuite.at (LT_AT_AUTOMAKE): New macro. > >* tests/subproject.at: Use it. Do not call `autoreconf' in > >tests, since it will try to reconfigure `sub/ltdl', which > >breaks `make check' during `distcheck' because of a readonly > >source tree.
Solaris, combining a bunch of convenience archives
Apparently, both the Solaris compiler driver `cc' and the linker fail when only given a bunch of convenience archives, but no plain object, iff for example in 64bit mode like with CFLAGS=-xarch=v9 because they seem to try to infer the link mode by the type of the first object they encounter (tested on sparc-sun-solaris2.8): | ld: warning: file .libs/libconv.a(conv.o): wrong ELF class: ELFCLASS64 A fix would be to force the linker into 64bit mode (with `-64'), when libtool does the link with `$LD'. We can do that in libtool.m4's _LT_ENABLE_LOCK together with the other such settings (what an inappropriate macro place and name, though, by the way), patch to follow when tested. Since on Solaris we sometimes use `$CC' for linking though (CVS HEAD uses $CC instead of $LD in this case), this is not sufficient. AFAICS the linker driver fails when all he gets is `-Wl,..' args: $ cc -G -h libfoo.so.0 -o .libs/libfoo.so -Wl,-z -Wl,allextract,.libs/libconv.a -Wl,-z -Wl,defaultextract -ldl -laio -lm -lnsl -lsocket -lc -xarch=v9 -mt usage: cc [ options] files. Use 'cc -flags' for details $ One workaround for the user would be to add a dummy object to the link line. I haven't found a good way to persuade the compiler driver to invoke the linker anyway yet.. does anybody have a better idea than going back to linking with $LD (maybe only in the 64bit case)? Any suggestions? And yes, I'll expand tests/convenience.at to cover this (as well as using something like `-export-symbols-regex *' optionally). This issue has been reported by Brian Barrett against branch-1-5, but is present in all Libtool branches, with the different facets shown above. Cheers, Ralf
Re: ltdl sillyness
Hi Peter, * Peter O'Gorman wrote on Wed, Oct 12, 2005 at 03:58:29PM CEST: > Hi, > I just spent the last several hours trying to find out why a package was > not building for me on Tru64 4.0. Turns out to have been a ltdl bug or two. > I was hitting a libltdl assert (assertion dirname) and when I figured out > why, I patched ltdl to check that dir was set before calling > tryall_dlopen_module. Does a simple test expose this on Tru64? Try something like adding a call to mdemo-exec that tries ( cd mdemo && ./mdemo foo1.la libfoo2.la ) (i.e., without path) and if this exposes it, please commit along with it. (It doesn't expose it on GNU/Linux.) > This done, I got a much more useful error message and > discovered that libltdl was not loading any files in dependency_libs that > were specified -Lpath -lfoo. Gaah! This bug has been in ltdl ever since 2001-02-22, since the MT API was introduced. Good catch! Can we have a cheap test for this as well? I'd be fine with putting the corresponding tests in CVS HEAD only for now, and if you have time constraints, I can try to write them later. > Okay to apply to branch-1-5 and forward port? Yes. The `dir' test is certainly ok, the other part looks as if it does not cause regressions (and passes on GNU/Linux), but the semantics of freeing the non-local object rather than the local one truly suck. Watch out, the load_deplibs part in HEAD is changed. Cheers, Ralf > Index: ChangeLog > 2005-10-12 Peter O'Gorman <[EMAIL PROTECTED]> > > * libltdl/ltdl.c (find_module): Check that dir is set. > (load_deplibs): Don't free the user search paths too early. >
Re: Solaris, combining a bunch of convenience archives
* Albert Chin wrote on Wed, Oct 12, 2005 at 07:42:21PM CEST: > On Wed, Oct 12, 2005 at 02:18:28PM +0200, Ralf Wildenhues wrote: > > Since on Solaris we sometimes use `$CC' for linking though (CVS HEAD > > uses $CC instead of $LD in this case), this is not sufficient. AFAICS > > the linker driver fails when all he gets is `-Wl,..' args: > > > > $ cc -G -h libfoo.so.0 -o .libs/libfoo.so -Wl,-z > > -Wl,allextract,.libs/libconv.a -Wl,-z -Wl,defaultextract -ldl -laio -lm > > -lnsl -lsocket -lc -xarch=v9 -mt > > usage: cc [ options] files. Use 'cc -flags' for details > > I haven't found a good way to persuade the compiler driver to invoke the > > linker anyway yet.. does anybody have a better idea than going back to > > linking with $LD (maybe only in the 64bit case)? Any suggestions? > > Infer from -xarch=v9? I don't understand what you are trying to say with this comment. I have added `-xarch=v9' to the link line. cc ignores it. If I invoke ld directly, I have to add `-64', it does not understand `-xarch=v9',.. > I really don't want to go back to linking with $LD but you do not want to go back to using ld anyway (and rightly so!). I do not know how to solve this. > (and, what happens for C++ where you must link with $CC?). The `CC' driver understands `-xarch=v9' and hands `-64' to ld; also it does not fail when no objects are given. Cheers, Ralf
Re: Solaris, combining a bunch of convenience archives
* Albert Chin wrote on Wed, Oct 12, 2005 at 11:21:50PM CEST: > On Wed, Oct 12, 2005 at 09:02:08PM +0200, Ralf Wildenhues wrote: > > * Albert Chin wrote on Wed, Oct 12, 2005 at 07:42:21PM CEST: > > > On Wed, Oct 12, 2005 at 02:18:28PM +0200, Ralf Wildenhues wrote: > > > > > > I haven't found a good way to persuade the compiler driver to invoke the > > > > linker anyway yet.. does anybody have a better idea than going back to > > > > linking with $LD (maybe only in the 64bit case)? Any suggestions? > > > > > > Infer from -xarch=v9? > > > > I don't understand what you are trying to say with this comment. > > I have added `-xarch=v9' to the link line. cc ignores it. > > > > If I invoke ld directly, I have to add `-64', it does not understand > > `-xarch=v9',.. > > If libtool sees -xarch=v9, it should add -64 to the linker > command-line. Yes, certainly. This solves the issue for branch-1-5, where we use `$LD' to link. (Of course, we could backport using $CC for linking instead, but mind the following.) The other issue is rather independent of this (sorry for mixing it up in the descriptions): For CVS HEAD, where we use `$CC' to link, all I can think of is setting whole_archive_flag_spec= so that the compiler driver "sees" the objects, so that it actually *invokes* the linker instead of bailing, because it thinks it has nothing to give to the linker. See test below. By the way, this is | cc: Sun C 5.6 2004/07/15 and I would be grateful if someone with access to a newer compiler version could check whether this has been fixed in the meantime; we could then avoid punishing users with newer compilers. To test: echo 'int x = 3;' > a.c cc -Kpic -xarch=v9 -c a.c ar cru liba.a a.o cc -G -o liba.so -Wl,-z -Wl,allextract,liba.a -Wl,-z -Wl,defaultextract -xarch=v9 # the last one fails, but the next instead works (note the xarch is # necessary): cc -G -o liba.so a.o -xarch=v9 The same thing also happens in 32 bit mode: echo 'int x = 3;' > a.c cc -Kpic -c a.c ar cru liba.a a.o cc -G -o liba.so -Wl,-z -Wl,allextract,liba.a -Wl,-z -Wl,defaultextract # the last one fails Cheers, Ralf
Re: ltdl sillyness
* Peter O'Gorman wrote on Thu, Oct 13, 2005 at 06:52:00AM CEST: > Ralf Wildenhues wrote: > > > >Does a simple test expose this on Tru64? Try something like adding a > >call to mdemo-exec that tries > > ( cd mdemo && ./mdemo foo1.la libfoo2.la ) > >(i.e., without path) and if this exposes it, please commit along with > >it. (It doesn't expose it on GNU/Linux.) > > No, if the dlopen() call fails on a file thta exists, it drops through to > here. I'll come up with something to test it at the weekend. Hacky test, exposes on systems where LTDL_DLOPEN_DEPLIBS is defined: sed 's,foo1,foo2' foo1.la >foo2.la ./mdemo ./foo2.la # file not found error ./mdemo foo2.la # assertion Testing this worked with faking by defining LTDL_DLOPEN_DEPLIBS in config.h, on GNU/Linux, as well. (I don't think you need to do this in the test, since testing the other issue won't work here.) Cheers, Ralf
Re: ltdl sillyness
* Ralf Wildenhues wrote on Thu, Oct 13, 2005 at 02:17:20PM CEST: > > Hacky test, exposes on systems where LTDL_DLOPEN_DEPLIBS is defined: > > sed 's,foo1,foo2' foo1.la >foo2.la Erm: 's,foo1,foo2,g'. > ./mdemo ./foo2.la # file not found error > ./mdemo foo2.la # assertion Sorry
HEAD: LT_PATH_NM fix (was: libtool-HEAD, 20051007, cygwin)
[ from a thread on the libtool list ] * Charles Wilson wrote on Tue, Oct 11, 2005 at 04:06:14AM CEST: > Ralf Wildenhues wrote: > > >Please post tests/testsuite.log containing the failures (packed?). > >I cannot reproduce this on GNU/Linux (and you posting should be less > >work than me trying to reproduce it on cygwin :) > > attached. Contains pointer to a different buglet: | configure:4403: checking the name lister (/usr/bin/nm -B) interface | configure:4410: gcc -c -O2 conftest.c >&5 | conftest.c:1:23: warning: no newline at end of file | configure:4413: /usr/bin/nm -B "conftest.o" Applied the following trivial fix to CVS HEAD. Cheers, Ralf * libltdl/m4/libtool.m4 (LT_PATH_NM): End test source with newline. Reported by Charles Wilson <[EMAIL PROTECTED]>. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.26 diff -u -r1.26 libtool.m4 --- libltdl/m4/libtool.m4 9 Oct 2005 06:25:03 - 1.26 +++ libltdl/m4/libtool.m4 13 Oct 2005 13:22:01 - @@ -2927,7 +2927,7 @@ AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface], [lt_cv_nm_interface="BSD nm" - printf "int some_variable = 0;" > conftest.$ac_ext + echo "int some_variable = 0;" > conftest.$ac_ext (eval echo "\"\$as_me:__oline__: $ac_compile\"" >&AS_MESSAGE_LOG_FD) (eval "$ac_compile" 2>conftest.err) cat conftest.err >&AS_MESSAGE_LOG_FD
Re: Solaris, combining a bunch of convenience archives
* Ralf Wildenhues wrote on Thu, Oct 13, 2005 at 09:19:06AM CEST:
> * Albert Chin wrote on Wed, Oct 12, 2005 at 11:21:50PM CEST:
> >
> > If libtool sees -xarch=v9, it should add -64 to the linker
> > command-line.
>
> Yes, certainly. This solves the issue for branch-1-5, where we use
> `$LD' to link. (Of course, we could backport using $CC for linking
> instead, but mind the following.)
Here's a (pretty minimal) fix for branch-1-5. OK?
I don't have access to a 64-bit sparc system with GNU ld. Can anybody
confirm that `-m elf64_sparc' is the correct thing to add? (Without
confirmation I'll leave the GNU ld case empty before committing.)
Cheers,
Ralf
* libtool.m4 (_LT_AC_LOCK) [ solaris ]: Add `-64' to $LD if
necessary, to permit combining of several convenience libs
without any further objects added.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 14 Oct 2005 13:34:35 -
@@ -574,6 +574,22 @@
CFLAGS="$SAVE_CFLAGS"
fi
;;
+sparc*-*solaris*)
+ # Find out which ABI we are using.
+ echo 'int i;' > conftest.$ac_ext
+ if AC_TRY_EVAL(ac_compile); then
+case `/usr/bin/file conftest.o` in
+*64-bit*)
+ case $lt_cv_prog_gnu_ld in
+ yes*) LD="${LD-ld} -m elf64_sparc" ;;
+ *)LD="${LD-ld} -64" ;;
+ esac
+ ;;
+esac
+ fi
+ rm -rf conftest*
+ ;;
+
AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
[*-*-cygwin* | *-*-mingw* | *-*-pw32*)
AC_CHECK_TOOL(DLLTOOL, dlltool, false)
Re: [patch 07/19] 291-gary-centralise-INCLTDL.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Fri, Oct 14, 2005 at 05:38:38PM CEST:
> Redone to fix the problems you encountered in the other thread
> about this patch. Okay to commit?
Erm, no? This patch is completely identical to the one I reverted.
Unless I missed something very badly, LT_WITH_LTDL is still not
required (and I would likely reject a patch that changes this),
and as such, the synching does not necessarily happen.
Gary, "fixing" this seems really low-importance to me, even if there
was a trivial fix available. The current code does not show a bug,
it's just a bit ugly because repetitive. Other stuff is much more
important.
Cheers,
Ralf, now off to the other stuff..
> libltdl/m4/ltdl.m4 | 19 +--
> 1 files changed, 5 insertions(+), 14 deletions(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libltdl/m4/ltdl.m4 (LTDL_CONVENIENCE, LTDL_INSTALLABLE): Remove
> AC_SUBST of LIBLTDL, LTDLINCL, and all mention of INCLTDL.
> (LT_WITH_LTDL): Due to order constraints between LTDL_CONVENIENCE,
> LTDL_INSTALLABLE, LT_WITH_LTDL & LTDL_INIT, we can safely AC_SUBST
> LIBLTDL and LTDLINCL here. Also, remember to synch INCLTDL.
>
> Index: libtool--devo--1.0/libltdl/m4/ltdl.m4
> ===
> --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4
> +++ libtool--devo--1.0/libltdl/m4/ltdl.m4
> @@ -69,13 +69,6 @@ case $enable_ltdl_convenience in
>esac
> LIBLTDL='${top_builddir}'"${lt_ltdl_dir+/$lt_ltdl_dir}/libltdlc.la"
> LTDLINCL='-I${top_srcdir}'"${lt_ltdl_dir+/$lt_ltdl_dir}"
> -
> -AC_SUBST([LIBLTDL])
> -AC_SUBST([LTDLINCL])
> -
> -# For backwards non-gettext consistent compatibility...
> -INCLTDL="$LTDLINCL"
> -AC_SUBST([INCLTDL])
> ])# LTDL_CONVENIENCE
>
> # AC_LIBLTDL_CONVENIENCE accepted a directory argument in older libtools,
> @@ -125,13 +118,6 @@ else
>LIBLTDL="-lltdl"
>LTDLINCL=
> fi
> -
> -AC_SUBST([LIBLTDL])
> -AC_SUBST([LTDLINCL])
> -
> -# For backwards non-gettext consistent compatibility...
> -INCLTDL="$LTDLINCL"
> -AC_SUBST([INCLTDL])
> ])# LTDL_INSTALLABLE
>
> # AC_LIBLTDL_INSTALLABLE accepted a directory argument in older libtools,
> @@ -223,6 +209,11 @@ m4_if(_LTDL_MODE, [subproject],
> [],
> [LTDL_INIT
> AC_DEFUN([LTDL_INIT], [])])])
> +
> +AC_SUBST([LIBLTDL])
> +AC_SUBST([LTDLINCL])
> +dnl For backwards non-gettext consistent compatibility...
> +AC_SUBST([INCLTDL], ["$LTDLINCL"])
> ])# LT_WITH_LTDL
>
> # Old name:
Re: [patch 02/19] 284-gary-report-macro-files-for-aclocal.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 05:28:20PM CEST: > Ralf Wildenhues wrote: > > >What I meant in the other thread we were discussing this: add right here > >something like this: > >func_echo "or instead follow the advice about > >\`AC_CONFIG_MACRO_DIR' below." > > > >since the macros exist below $ltdldir/m4 anyway.. > > Oh, okay. Not quite that simple as the 'following advice' may not be > printed, depending on the state of various flags set by scanning and > command line options. Here is a replacement patch that tries to > address your concerns, but being mindful of not reading badly regardless > of the flag values: OK, please apply. Thanks for redoing. By the way: please fix your patch mailing system not to ever send in format=flowed again. I had to apply all your redone patches manually. :-/ Cheers, Ralf > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Copying just libtool.m4 for hand maintained > aclocal.m4 doesn't work. List all required files in that case, > using the files from installed libltdl if available. Also, list > the additional files required when using libltdl. > Reported by Patrick Welche <[EMAIL PROTECTED]>.
Re: [patch 03/19] 285-gary-diagnose-missing-LT_WITH_LTDL.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 10:47:53PM CEST: > > > Now that I see this: Please remove these two lines, or make them as > > little intrusive as branch-1-5 was: > > Actually, it already triggers under fewer circumstances than 1.5.x! > > > grepped for '^AC_PROG_RANLIB'. > > Rationale: a `libtoolize' that'll bug me every time because of > > > > m4_if([I_USE_LIBTOOL], > > [AM_PROG_LIBTOOL], > > [AC_PROG_RANLIB]) > > > > will make me not listen to it. Besides, I *could* be using libltdl > > as subpackage (and thus `libtoolize --ltdl') but not wanting to use > > libtool in the parent package. > > But I take your point. This patch only runs the test when --ltdl is > not being used. OK. Fine, please apply! I've found another bug in the related area; but since I believe it existed before this and the previous patch, I'll post it separately. Cheers, Ralf > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Move the consistency checks... > (func_check_macros): ...into here. Also suggest LT_WITH_LTDL if > appropriate.
Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Thu, Oct 13, 2005 at 06:40:59PM CEST: > Ralf Wildenhues wrote: > >Do you want the (non)recursive/subproject info as argument to > > LT_WITH_LTDL > >or > > LT_CONFIG_LTDL_DIR > > Eek! That leaked in from the ancient past. My first implementation tried > to put the mode argument in LT_WITH_LTDL, but for various reasons that > turned out to be untenable, so I moved it to LT_CONFIG_LTDL_DIR (which > actually is conceptually nicer anyway). I've removed all evidence of > the earlier implemention for sure this time! Thanks! > >I have found more nits, see inline. Also, please remember: > >- adjust doc plus makefiles for whatever you agree on wrt. *_LTLIBRARIES > > DEFS, AM_CPPFLAGS, AM_CFLAGS: `+=' vs `='. > > Done. Although I've moved the contents of DEFS into AM_CPPFLAGS to reduce > the number of magic variables a little. OK, even better, although I have a hard time seeing whether this works in all cases.. > >And please actually do the commit only together with the followup > >patches needed to implement the functionality, so CVS HEAD is not in > >broken state for long. Thank you. > > Actually, this patch doesn't break libtool at all... the testsuite still > passes, it's just that recursive mode isn't yet implemented. D'oh. Thank you, I overlooked that! > >Now, how's that gonna work if the user uses a name different from > >`libltdl/' as subdir? The paths in `libltdl/Makefile.inc' are pretty > >hardcoded to start with `libltdl/'! > > > >No need to change the implementation IMHO, but it may be good to adjust > >above paragraph to match the limitation to firmly state: if you use > >nonrecursive, that subdir better be named `libltdl' and nothing else! > > I had started a patch to substitute in the correct value as libtoolize > copied Makefile.inc into the project tree. But figure that is icing. > I'd forgotten that you *must* use libltdl for nonrecursive. Good catch, > thanks! I'll also add to [298] a note that a LIBOBJDIR capable Automake > and Autoconf are required for this mode to work as it stands (as per > your review of that patch) -- we certainly have room to tweak libtoolize > to replicate the trick libtool itself uses to workaround the problem > later... OK, fine with me. * Gary V. Vaughan wrote on Fri, Oct 14, 2005 at 05:34:28PM CEST: > Tweaked this patch slightly to allow for the next one to work whether > or not SUBDIR_LIBOBJS are supported by the user's autotools. Okay to > commit? I have a couple of gripes with it: - First, LTCOMPILE is not published interface by Automake, - Second, you kill dependency tracking for the LTLIBOBJS, Considering this, maybe this is too high a price to pay for gaining unchanged AM_CPPFLAGS, DEFS, and AM_LDFLAGS. What do you think? Sorry for not thinking enough about this before, but now that I see this, I believe it needs to be addressed. A couple of trivial nits: - I believe SUBDIR_LIBOBJS is too generic a name to be used in third-party Makefiles. (Prepend LT_ or LTDL_ or so) - list libltdl/Makefile.inc before libltdl/Makefile.am in ltdldatafiles > Incidentally, this also removes the troublesome '## %%% BEGIN' magic from > Makefile.am. Nice! Could you please repost the patch without format=flowed, so I can apply it cleanly. Thank you. I'm seeing weirdnesses with libtoolize but want to make sure they are not from me messing up the merge. Cheers, Ralf > from Gary V. Vaughan <[EMAIL PROTECTED]> > * configure.ac: Move SUBDIR_LIBOBJS check from here... > * libltdl/m4/ltdl.m4 (_LT_CHECK_SUBDIR_LIBOBJS: ...to here. > (LT_INIT): Adjust. > * libltdl/Makefile.inc: New file, factored out of Makefile.am for > use in non-recursive libltdl installations. > * Makefile.am: include it. > (libltdl/Makefile.am): Adjust to build from the new > libltdl/Makefile.inc. > * bootstrap: Adjust. > * doc/libtool.texi (Invoking libtoolize): Document the new modes > and libtoolize option to select them. > * libtoolize.m4sh: Parse new options, --nonrecursive, --recursive > and --subproject. Install the appropriate files with --ltdl > according to the selected mode. > (func_scan_files): If --subproject, --recursive or --nonrecursive > options were not given, use the value from LT_CONFIG_LTDL_DIR; if > a mode was given, and there is also an argument to > LT_CONFIG_LTDL_DIR, ensure they are the same. > * NEWS: Updated.
libtoolize weirdness (after 285-gary)
Hi Gary, Sorry for the terse bug report, I hope this is understandable: cat >configure.ac <<\EOF AC_INIT(a,1,b) AC_CONFIG_MACRO_DIR([ltdl/m4]) AC_CONFIG_SUBDIRS(ltdl) AM_INIT_AUTOMAKE AC_WITH_LTDL(ltdl) AC_LIB_LTDL(ltdl) AC_PROG_LIBTOOL AC_CONFIG_FILES(Makefile) AC_OUTPUT EOF libtoolize --ltdl=ltdl # this is fine aclocal -I ltdl/m4 libtoolize --ltdl=ltdl The second `libtoolize' invocation now also asks me to | libtoolize: You should add the contents of `ltdl/m4/ltversion.m4' to `aclocal.m4'. It seems to compare the serial 7 from aclocal.m4:AM_CONDITIONAL with the serial 2132 from ltdl/m4/ltversion.m4. Cheers, Ralf
Re: darwin: mix up of .dylib and .bundle
[ taking out bug-libtool ] Hi Christoph, Peter, * Christoph Egger wrote on Sun, Oct 16, 2005 at 07:58:39PM CEST: > > Christoph Egger wrote: > > > > > file -L /path/to/with/ggbundle/in/it | grep bundle will return true! > > > > Let me look into a patch, probably testing for 'Mach-O bundle' is better > > than testing for 'bundle'. > > I've attached a patch, which fixes this bug. > I also added comments (two lines) which explains what it does and why. > libtool no longer needs to worry about any directory names. A couple of random thoughts: With the sed in place, should not grepping for `bundle' suffice? A casual glance at my "magic" file suggests the possibility of `Mach-O ' `Mach-O fat file ' `Macintosh MacBinary data ' (commented out) before the `bundle'. This might be completely unrealistic, but I don't know darwin at all, so darwin experts please decide. :) Also, can't we eliminate the extra process? How about a grep for `: [^:]* bundle' instead, given above? (Watch out, ltmain.m4sh needs the brackets m4-quoted!) Cheers, Ralf
Re: If -xarch passed in, don't set compiler_flags _only_ for GCC
Hi Albert, Keith, Donald, * Albert Chin wrote on Mon, Oct 17, 2005 at 11:07:04PM CEST: > HEAD sets compiler_flags in the code below regardless of whether or > not GCC is the compiler. Why does branch-1-5 do it differently? If > someone is building a 64-bit library with the Sun C++ compiler, > -xarch=v9 won't get passed through and ld will try to create a 32-bit > library, resulting in an error. Thanks for the patch. Applied to branch-1-5. Cheers, Ralf > 2005-10-17 Albert Chin-A-Young <[EMAIL PROTECTED]> > > * ltmain.in: When accepting -64, -mips[0-9], et. al. compiler > flags, don't set compiler_flags only for GCC as the vendor > compiler also requires this flag. Sync with HEAD. > Reported by Donald Anderson <[EMAIL PROTECTED]>.
Re: 286-gary-libtoolize-recursive-ltdl.diff
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 17, 2005 at 12:55:05PM CEST: > Ralf Wildenhues wrote: > > I have a couple of gripes with it: > > - First, LTCOMPILE is not published interface by Automake, > > - Second, you kill dependency tracking for the LTLIBOBJS, > > > > Considering this, maybe this is too high a price to pay for gaining > > unchanged AM_CPPFLAGS, DEFS, and AM_LDFLAGS. What do you think? > > Sorry for not thinking enough about this before, but now that I see > > this, I believe it needs to be addressed. > > I wavered on this myself for a while, and on balance, I think you're > right: we need hackish workarounds to make it work properly. I've > reverted to using AM_CPPFLAGS and AM_LDFLAGS. OK to apply after changing the libtool.texi part to also reflect this. > > Could you please repost the patch without format=flowed, so I can apply > > it cleanly. Thank you. I'm seeing weirdnesses with libtoolize but want > > to make sure they are not from me messing up the merge. > > Reredone here. I also posted a patch to fix your weirdness (well, not > literally *yours*, but you know what I mean!) in that thread. OK. Thank you, for all of this work, and sorry for the latency. Cheers, Ralf
speedup bootstrap
While working on the outstanding patch queue, I finally got fed up enough with CVS HEAD bootstrap and all the pizzas I had to eat each time, that it needed to be fixed. ;-) m4 tail recursion sucks performance-wise, if the argument lists are long, because: even if shift/m4_shiftn is fast(?), the whole stuff needs to be copied anyway for the new macro call. Just to make clear just how much of an issue this is: the code recurses as much as 600 C function calls deep (as seen by randomly interrupting m4 in a debugger; I haven't attempted to find the true maximum). So, let's do in some manual tail recursion elimination. Unmodified, CVS Autoconf: $ \time ./bootstrap 688.51user 6.78system 12:00.46elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1760773minor)pagefaults 0swaps ditto, Autoconf-2.59: 676.61user 6.32system 11:39.15elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1741926minor)pagefaults 0swaps After rewriting lt_join and lt_dict_filter, CVS Autoconf: $ \time ./bootstrap 188.87user 4.57system 3:36.43elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (5major+1202187minor)pagefaults 0swaps After further rewriting lt_combine, CVS Autoconf: $ \time ./bootstrap 158.85user 4.04system 3:02.42elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1094468minor)pagefaults 0swaps ditto, Autoconf-2.59: 138.17user 3.20system 2:42.03elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+897776minor)pagefaults 0swaps OK to apply the combined patch below? Remarks: - I commented _lt_decl_filter in order to be able to understand it. - lt_unquote is an ugly helper to get rid of the quotes introduced by m4_split. Is there a documented way (macro to call) to do this? - all generated configure scripts in the source tree compared equal to the previous version, with both CVS HEAD Autoconf and 2.59. I hope that uncovered all issues.. - I guess Autoconf could benefit as well from rewriting a few of their m4sugar functions. I believe it can be done similarly, but haven't thought of whitespace-in-m4-lists issues yet -- ltsugar does not have to deal with those by preserving it. - Libtool branch-1-5 is still faster to bootstrap (one configure script less, by the way; CVS Autoconf): 62.73user 1.79system 1:07.73elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+492214minor)pagefaults 0swaps - Have I ever mentioned that I am a fan of procedural rather than functional languages? :-> - Should you ever be offered a job that involves m4 macros and is paid by changed/created SLOC, no matter how much: turn it down! With sincere apologies to Gary for doing this before finishing reviews. Cheers, Ralf * libltdl/m4/ltsugar.m4 (lt_join, lt_combine, lt_dict_filter): Rewrite to eliminate tail recursion; use .. (lt_unquote): New trivial helper macro. * libltdl/m4/libtool.m4 (_lt_decl_filter): Document. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.27 diff -u -r1.27 libtool.m4 --- libltdl/m4/libtool.m4 13 Oct 2005 13:22:55 - 1.27 +++ libltdl/m4/libtool.m4 23 Oct 2005 09:02:45 - @@ -335,6 +335,10 @@ # - m4_define([lt_decl_tag_varnames], [_lt_decl_filter([tagged?], [yes], $@)]) + + +# _lt_decl_filter(SUBKEY, VALUE, [SEPARATOR], [VARNAME1..]) +# - m4_define([_lt_decl_filter], [m4_case([$#], [0], [m4_fatal([$0: too few arguments: $#])], Index: libltdl/m4/ltsugar.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltsugar.m4,v retrieving revision 1.1 diff -u -r1.1 ltsugar.m4 --- libltdl/m4/ltsugar.m4 22 Aug 2005 22:33:35 - 1.1 +++ libltdl/m4/ltsugar.m4 23 Oct 2005 09:02:45 - @@ -23,12 +23,12 @@ [1], [], [2], [[$2]], [m4_ifval([$2], - [m4_ifval([$3], -[[$2][$1][]$0([$1], m4_shiftn(2, $@))], - [m4_if([$#], [3], - [$2], - [$0([$1], [$2], m4_shiftn(3, $@))])])], - [$0([$1], m4_shiftn(2, $@))])])[]dnl + [[$2][]m4_foreach(_lt_Arg, lt_car([m4_shiftn(2, $@)]), + [_$0([$1], _lt_Arg)])], + [$0([$1], m4_shiftn(2, $@))])])[]dnl +]) +m4_define([_lt_join], +[m4_ifval([$2],[$1][$2])[]dnl ]) @@ -43,6 +43,7 @@ [m4_if([$#], 0, [m4_fatal([$0: cannot be called without arguments])], [$#], 1, [], [m4_dquote(m4_shift($@))])]) +m4_define([lt_unquote], $1) # lt_combine(SEP, PREFIX-LIST, INFIX, SUFFIX1, [SUFFIX2...]) @@ -52,14 +53,11 @@ # has the form PREFIXmINFIXSUFFIXn. m4_define([lt_combine],
Re: speedup bootstrap
Hi Gary, Peter,
* Gary V. Vaughan wrote on Mon, Oct 24, 2005 at 10:32:52AM CEST:
> Peter O'Gorman wrote:
> >Ralf Wildenhues wrote:
> >|
> >| So, let's do in some manual tail recursion elimination.
>
> Wow! Great work :-D
Thanks!
> >| OK to apply the combined patch below?
> >
> >You know, I looked at sppeding up bootstrap for myself about a year ago,
> >but couldn't figure out the cause.
Don't be fooled into thinking that this patch needed less than a few
months, on and off. I don't know how experts profile m4 scripts, but I
first tried removing macros one by one (starting with a good guess) and
ended up manually #define'ing DEBUG_SYM in m4-1.4.3 together with a form
of manual statistical profiling: interrupt m4 in gdb every now and then,
look where it's at. :)
valgrind's massif for overall memory usage profiling showed me m4 uses
little heap until it starts outputting; that's what finally got me to
get to the point that we needed to make use of storage in order to gain
on execution time. Some off-list discussion with Stepan (thanks, BTW!)
got me on the right track.
> >This is okay, even thouh I don't actually understand it :)
Before this patch, we did this (informal notation):
join(Separator, Arg1, Arg2, ...)
{
if Arg1 last arg
produce Arg1
else if Arg1 empty
call join(Separator, Arg2, Arg3, ...)
else
call join(Separator, Arg1Separator, Arg2, ...)
end if
}
which ends up recursively at:
-> ...
join(Separator, Arg1SeparatorArg2Separator...ArgN-1, ArgN)
->
Arg1SeparatorArg2Separator...ArgN
Now we do roughly this:
join(Separator, Arg1, Arg2, ...)
{
if Arg1 nonempty
produce Arg1
for Arg in [Arg2, ..., ArgN]; do
produce SeparatorArg2
end for
else
call join(Separator, Arg2, Arg3, ...)
end if
}
Similarly with the other two functions, except that lt_combine actually
did a two-staged recursion, and in that recursion called lt_join in each
step.
> No, not okay!
>
> I haven't tested the code yet, but I do remember that the areas you are
> touching are exceedingly delicate. And even though on a cursory look,
> your patch looks sane, this is something to apply after 2.0!
Please rethink this judgement again. I deliberately tried for a minimal-
invasive change; consistency-wise, it would probably be better to work
with m4 lists all the time instead of converting to and from; but my
patch actually keeps each of the three functions and their interfaces
the same.
Also, it might be much more efficient to change _some_ of the code not
to use the dictionary lookup code: a list of tagged/non-tagged variables
may easily be updated in _LT_DECL already; however, this is not a
minimal change, either.
> On the other hand, thankyou very much for taking the time to fix this
> problem! I'm going to add your patch to my quilt series and enjoy the
> speedup until 2.0 is done. It'll also mean that I'll have been able to
> give it a good workout before approving.
I can only rephrase: please rethink your post-2.0 judgement. Tell me
what you need to be convinced (test suite tests for these functions,
whatever).
Please also remember that, if _you_ use this, the old version will not
be tested any more. It might thus just as well break in between,
unnoticed, or be broken before, but breakage only uncovered later.
Surely I would like the patch to be dissected as much as possible before
applying it; I'd also love to see it given a whirl in the next alpha
release, though.
Cheers,
Ralf
Re: Debugging M4
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 24, 2005 at 01:03:29PM CEST: > > Valgrind is x86 specific unfortunately :-( Not any more. x86_64 works quite well, and ppc32 should work too, but it looks like it may have a couple more glitches yet. Cheers, Ralf
Re: [patch 01/19] 277-gary-rename-remaining-troublesome-ltdl-apis.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:25PM CEST:
> ChangeLog|0
> NEWS |9 +-
> doc/libtool.texi | 176
> +--
> libltdl/ltdl.c | 88 ++-
> libltdl/ltdl.h | 10 +--
> 4 files changed, 114 insertions(+), 169 deletions(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libltdl/ltdl.h, libltdl/ltdl.c (lt_dlhandle_first): Removed.
> * libltdl/ltdl.h, libltdl/ltdl.c (lt_dlhandle_next)
> (lt_dlhandle_find, lt_dlforeach): Removed...
> (lt_dlhandle_iterate, lt_dlhandle_fetch, lt_dlhandle_map): Similar
> functions that are multi-loader safe, and require a registered
> interface validator argument.
> * doc/libtool.texi: Updated.
> * NEWS: Updated.
OK to apply, with the nits below addressed.
Please also apply the then-freed part of your patch queue,
that should 284, 285, 286 I believe; with 286, please just
take one look at the additional tiny nit I found, see other mail.
Thank you!
Cheers,
Ralf
> Index: libtool--devo--1.0/NEWS
> ===
> --- libtool--devo--1.0.orig/NEWS
> +++ libtool--devo--1.0/NEWS
> @@ -4,11 +4,12 @@ New in 1.9h: 2005-??-??; CVS version 2.1
> * New tests for support of Automake subdir-objects.
> * Fix libltdl on static platforms.
> * New LT_CONFIG_LTDL_DIR macro.
> -* New lt_dlinterface_register, lt_dlinterface_set_data and
> - lt_dlinterface_get_data libltdl API calls to maintain separation of
> - concerns between modules loaded by different libraries.
> +* 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 between
> + modules loaded by different libraries.
> * Removed deprecated APIs from libltdl: lt_dlcaller_register,
> - lt_dlcaller_get_data, lt_dlcaller_set_data, lt_dlmutex_register,
> + lt_dlhandle_next, lt_dlhandle_find, lt_dlforeach, lt_dlmutex_register,
>lt_dlmutex_lock, lt_dlmutex_unlock, lt_dlmutex_seterror,
>lt_dlmutex_geterror, lt_dlmalloc, lt_dlrealloc, lt_dlfree.
> * Support for Portland Group compiler on GNU/Linux.
> Index: libtool--devo--1.0/doc/libtool.texi
> ===
> --- libtool--devo--1.0.orig/doc/libtool.texi
> +++ libtool--devo--1.0/doc/libtool.texi
> @@ -3734,35 +3734,85 @@ Furthermore, in order to save you from h
> handles of all the modules you have loaded, these functions allow you to
> iterate over libltdl's list of loaded modules:
>
> [EMAIL PROTECTED] int lt_dlforeach (@w{int ([EMAIL PROTECTED]) (lt_dlhandle
> @var{handle}, void * @var{data})}, @w{void * @var{data}})
> -For each loaded module call the function @var{func}. The argument
> [EMAIL PROTECTED] is the handle of one of the loaded modules, @var{data} is
> -the @var{data} argument passed to @code{lt_dlforeach}.
> -As soon as @var{func} returns a non-zero value for one of the handles,
> [EMAIL PROTECTED] will stop calling @var{func} and immediately return 1.
> -Otherwise 0 is returned.
> [EMAIL PROTECTED] {Type} lt_dlinterface_id
> +The opaque type used to hold the module interface details for each
> +registered libltdl client.
> [EMAIL PROTECTED] deftp
> +
> [EMAIL PROTECTED] {Type} int lt_dlhandle_interface (@w{lt_dlhandle
> @var{handle},} @w{const char [EMAIL PROTECTED])
Hmm, this @deftp definition is rendered a bit weird in the DVI, but I
suppose that is either deliberate (by texinfo) or a limitation. Dunno
what would be better here.
> +Functions of this type are called to check that a handle conforms to a
> +library's expected module interface when iterating over the global
> +handle list. You should be careful to write a callback function of
> +this type that can correctly identify modules that belong to this
> +client, both to prevent other clients from accidentally finding your
> +loaded modules with the iterator functions below, and vice versa. The
> +best way of doing this is to check that module @var{handle} conforms
better: `to do this'? (just a thought)
> +to the interface specification of your loader using @code{lt_dlsym}.
This is pretty inefficient: the user will actually have to store a list
of loaded modules itself. Hrmpf.
Ah, no, never mind. Your example below clarifies it.
(Maybe above is a bit difficult to understand?)
> +
> +The callback will be given @strong{every} module loaded by all the
> +libltdl module clients in the current address space, including any
Can we weaken this to: `The callback may be given every module..'?
Rationale: we might change to use a more efficient implementation later
(or have to use it for unrelated reasons), which will allow ltdl itself
to weed out the other modules at less cost; no need to restrict
ourselves not to be able to pass on tha
Re: 286-gary-libtoolize-recursive-ltdl.diff
Hi Gary, Just one more thing.. * Ralf Wildenhues wrote on Tue, Oct 18, 2005 at 10:23:44AM CEST: > * Gary V. Vaughan wrote on Mon, Oct 17, 2005 at 12:55:05PM CEST: > > Ralf Wildenhues wrote: > > > I have a couple of gripes with it: > > > - First, LTCOMPILE is not published interface by Automake, > > > - Second, you kill dependency tracking for the LTLIBOBJS, > > > > > > Considering this, maybe this is too high a price to pay for gaining > > > unchanged AM_CPPFLAGS, DEFS, and AM_LDFLAGS. What do you think? > > > Sorry for not thinking enough about this before, but now that I see > > > this, I believe it needs to be addressed. > > > > I wavered on this myself for a while, and on balance, I think you're > > right: we need hackish workarounds to make it work properly. I've > > reverted to using AM_CPPFLAGS and AM_LDFLAGS. > > OK to apply after changing the libtool.texi part to also reflect this. I noted what was AM_CPPFLAGS and DEFS before is only AM_CPPFLAGS now. I'm pretty sure that change is benign, except for one thing: Autoconf will set DEFS = -DHAVE_CONFIG_H as well, I guess, so it'll be listed twice on the command line, no? You don't need to set it in that case. Incidentally, can't we just remove our call to AC_CONFIG_HEADER in ltdl.m4 completely now? Untested, by the way. Cheers, Ralf
Re: [patch 01/19] 277-gary-rename-remaining-troublesome-ltdl-apis.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Tue, Oct 25, 2005 at 10:36:00AM CEST: > Ralf Wildenhues wrote: > > > >Please also apply the then-freed part of your patch queue, > > Before 277, I have (see my patch queue status mail from last Tue): Gah, I've been unaware of the fact that your patch queue mail *is* sorted. D'oh. > - patches/302-gary-libtoolize-config.diff > > http://lists.gnu.org/archive/html/libtool-patches/2005-10/msg00115.html > review pending Will do next. > >that should 284, 285, 286 I believe; > > After 302 is cleared to apply, that will unblock 277, 284 and 285. > 286 will then still be blocked by: > > + patches/303-gary-correct-included-file-matching-expression.diff > > http://lists.gnu.org/archive/html/libtool-patches/2005-10/msg00147.html > review pending OK, that one was my "next" before you wrote this, thinking it could come right after 285. > I might be able to apply the patches out of order, but I don't trust > myself to do a careful enough interdependency analysis -- plus I > already did extensive testing in the order they are queued, and it > seems like unnecessary additional work to retest everything after > twiddling the order when we need them all to go in to fix outstanding > known bugs in HEAD anyway. Hope that isn't too much of a pain for > you... No, that's fine. I just need a week to address a few issues after your queue is flushed. Cheers, Ralf
Re: FYI: subproject.at distcheck failure
Hi Gary, Sorry for the delay. * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 05:21:22PM CEST: > > After more testing, and an adjustment to libtoolize.at to compensate > for the slight change in output, okay to apply? This one is ok. It falls under the same "we need to revisit this wrt. subproject `make dist' failure" as a couple of other ones; but we've already said that we deal with that after we're through your queue. So please apply! Side note: it also gives a bit misleading output in case the user has something like AC_CONFIG_AUX_DIR([./libltdl/config]) instead of AC_CONFIG_AUX_DIR([libltdl/config]) because of the | +if test "$ltdldir/config" != "$auxdir"; then but I really don't care at the moment. We should not make shooting in the foot too hard. > Gary V. Vaughan wrote: > >You've uncovered a nice bug here. Fix below... > > > >Except that now libtoolize will need to handle populating the config > >directory properly, rather than relying on autoreconf to pick up the > >slack. The immediate problem with these tests is that automake looks > >at configure.ac instead of sub/ltdl/configure.ac, and decides that > >it doesn't need to create sub/ltdl/config/compile, so the build in > >sub/ltdl fails. Cheers, Ralf > libtoolize.m4sh | 28 ++-- > tests/libtoolize.at |7 ++- > 2 files changed, 20 insertions(+), 15 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Always copy pkgconfig_files for --ltdl, incase > ltdl needs additional things not found by automake when looking at > the parent project configury. > * tests/libtoolize.at: Adjust.
Re: [Patch] libtoolize weirdness (after 285-gary)
Hi Gary, * Gary V. Vaughan wrote on Tue, Oct 25, 2005 at 04:10:40PM CEST: > Okay to commit? Yes, please. Please commit all patches that aren't held up any more; I will continue review after that. Cheers, Ralf > Fixes a dumb bug, where the serial numbers of m4_included files are > looked up incorrectly. Fixes a dumber bug, where the serial numbers > of copied-to-aclocal.m4-verbatim were looked up using clairvoyance. > > libtoolize.m4sh | 22 +- > 1 files changed, 13 insertions(+), 9 deletions(-) > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Don't use func_serial_update as a copy > function for libtool m4 files with no macro_regex. If the > files are copied directly into aclocal.m4, because > AC_CONFIG_MACRO_DIR isn't set for example, there is no way > to tell what serial number goes with what source file. > (func_serial_update): For future-proofing, only make the second > serial number check if the destination file wasn't m4_included > into aclocal.m4 (and hence updated automatically by the cat of > copying a new version to the dest directory).
libtoolize test failures
Hi Gary, Tests 2 and 3 now fail, like this (bootstrapped with 2.59/1.9.2). Could you please look into this, to see whether just the tests need updating or `libtoolize' is wrong. If you update the tests, note that the then-enabled followup AT_CHECKs will also fail. Thanks, Ralf | 2. libtoolize.at:95: testing ... | libtoolize.at:119: /tmp/build/libtoolize --copy | | libtoolize.at:140: /tmp/build/libtoolize --copy | | --- experr2005-10-26 14:08:30.0 +0200 | +++ /tmp/build/tests/testsuite.dir/at-stderr 2005-10-26 14:08:30.0 +0200 | @@ -1,2 +1,5 @@ | libtoolize: `config/ltmain.sh' is newer: use `--force' to overwrite | +libtoolize: `m4/argz.m4' exists: use `--force' to overwrite | libtoolize: `m4/ltoptions.m4' exists: use `--force' to overwrite | +libtoolize: `m4/ltsugar.m4' exists: use `--force' to overwrite | +libtoolize: `m4/ltversion.m4' exists: use `--force' to overwrite | --- expout2005-10-26 14:08:30.0 +0200 | +++ /tmp/build/tests/testsuite.dir/at-stdout 2005-10-26 14:08:30.0 +0200 | @@ -1,6 +1,3 @@ | libtoolize: putting files in AC_CONFIG_AUX_DIR, `config'. | libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. | libtoolize: `m4/libtool.m4' is already up to date. | -libtoolize: `m4/argz.m4' is already up to date. | -libtoolize: `m4/ltsugar.m4' is already up to date. | -libtoolize: `m4/ltversion.m4' is already up to date. | 2. libtoolize.at:95: 2. libtoolize macro serial update (libtoolize.at:95): FAILED (libtoolize.at:140) | | 3. libtoolize.at:186: testing ... | libtoolize.at:213: /tmp/build/libtoolize --copy --install | | --- experr2005-10-26 14:08:30.0 +0200 | +++ /tmp/build/tests/testsuite.dir/at-stderr 2005-10-26 14:08:30.0 +0200 | @@ -1,2 +1,2 @@ | libtoolize: `config/ltmain.sh' is newer: use `--force' to overwrite | -libtoolize: `m4/ltoptions.m4' is newer: use `--force' to overwrite | +libtoolize: `m4/ltoptions.m4' exists: use `--force' to overwrite | 3. libtoolize.at:186: 3. libtoolize config files serial update (libtoolize.at:186): FAILED (libtoolize.at:213)
FYI: bootstrap warning
Hi Eric,
* Eric Blake wrote on Wed, Oct 26, 2005 at 02:55:11PM CEST:
> According to Eric Blake on 10/26/2005 6:46 AM:
> >
> > * Makefile.am (vcl-tmp): Avoid warnings from diff.
> > * bootstrap: Avoid warnings from find.
Which find version is this?
> Also, emacs whitespace-cleanup doesn't like the fact that bootstrap has
> space followed by a literal tab in my_sed_traces; and it tried to 'help'
> me by flattening that into a single tab (of course, changing the sed
> expression in the process). Is it safe to use \t instead of literal tab
> in a sed expression?
No, it's not. I have applied the patch below to CVS HEAD, which should
fix all issues.
Thanks for reporting!
Cheers,
Ralf
2005-10-26 Eric Blake <[EMAIL PROTECTED]>,
Ralf Wildenhues <[EMAIL PROTECTED]>
* Makefile.am (vcl-tmp): Avoid warnings from diff.
* bootstrap: Avoid warnings from find.
(lt_tab): Use to prevent editor whitespace "cleanup".
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.173
diff -u -r1.173 Makefile.am
--- Makefile.am 26 Oct 2005 10:42:02 - 1.173
+++ Makefile.am 26 Oct 2005 14:20:09 -
@@ -138,7 +138,7 @@
vcl-tmp:
@set dummy `$(MKSTAMP) < $(srcdir)/ChangeLog`; shift; \
echo "$$1" > vcl.tmp; \
- diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null \
+ diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null 2>/dev/null \
|| (echo "Updating stamp-vcl"; cp vcl.tmp $(srcdir)/stamp-vcl)
[EMAIL PROTECTED] -f vcl.tmp
Index: bootstrap
===
RCS file: /cvsroot/libtool/libtool/bootstrap,v
retrieving revision 1.71
diff -u -r1.71 bootstrap
--- bootstrap 26 Oct 2005 10:42:03 - 1.71
+++ bootstrap 26 Oct 2005 14:20:09 -
@@ -44,13 +44,14 @@
# Extract auxdir and m4dir from configure.ac:
+lt_tab=' '
my_sed_traces='s,#.*$,,; s,^dnl .*$,,; s, dnl .*$,,;
- /AC_CONFIG_AUX_DIR[^_]/ {
- s,^.*AC_CONFIG_AUX_DIR([[ ]*\([^])]*\).*$,auxdir=\1,; p;
-};
- /AC_CONFIG_MACRO_DIR/ {
- s,^.*AC_CONFIG_MACRO_DIR([[ ]*\([^])]*\).*$,m4dir=\1,; p;
-};
+ /AC_CONFIG_AUX_DIR[^_]/ {
+ s,^.*AC_CONFIG_AUX_DIR([[ '"$lt_tab"']*\([^])]*\).*$,auxdir=\1,; p;
+ };
+ /AC_CONFIG_MACRO_DIR/ {
+ s,^.*AC_CONFIG_MACRO_DIR([[ '"$lt_tab"']*\([^])]*\).*$,m4dir=\1,; p;
+ };
d;'
eval `cat configure.ac 2>/dev/null | $SED "$my_sed_traces"`
@@ -65,7 +66,7 @@
WARNING: `lt~obsolete.m4'). After that, retry this bootstrap.
EOF
-find . \( -name autom4te.cache -o -name libtool \) -depth -print \
+find . -depth \( -name autom4te.cache -o -name libtool \) -print \
| grep -v '{arch}' \
| xargs rm -rf
tagtrace test: skip for older autoconf version
OK to apply? To expose: bootstrap with Autoconf CVS, then put 2.59 only in your PATH, then make check TESTS=tests/tagtrace.test VERBOSE=x TESTSUITE_FLAGS=-V It works the other way round, by the way. Cheers, Ralf Index: tests/tagtrace.test === RCS file: /cvsroot/libtool/libtool/tests/tagtrace.test,v retrieving revision 1.7 diff -u -r1.7 tagtrace.test --- tests/tagtrace.test 22 Apr 2005 10:10:30 - 1.7 +++ tests/tagtrace.test 26 Oct 2005 13:06:15 - @@ -32,6 +32,12 @@ func_skip "This test requires write access to the source tree" fi +if ( cd "$srcdir" && "$AUTOCONF" --trace 'LT_SUPPORTED_TAG:$1' ) 2>&1 >/dev/null | + grep "Autoconf version .*is required" >/dev/null; then + func_error "This test requires an Autoconf version at least as new" + func_skip "as the one that was used to bootstrap Libtool" +fi + # Abort as soon as something fails. set -e
Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff
Hi Eric,
* Eric Blake wrote on Wed, Oct 26, 2005 at 05:11:57PM CEST:
> CVS head is currently broken on cygwin. It looks like the patch
> to rename lt_dlhandle_next to lt_dlhandle_iterate was incomplete.
Yep. And we see me goofing up once more: loadlibrary.c:vm_open()
really _has_ to iterate over _all_ modules. One could argue this to be
internal use, but we do rely on this now-undocumented detail of
lt_dlhandle_iterate here.
Now that I look at it, there's potential for more subtle breakage in
loadlibrary.c, but this one independent of our recent changes:
| /* Append a `.' to stop Windows from adding an
| implicit `.dll' extension. */
| searchname = MALLOC (char, 2+ LT_STRLEN (filename));
| if (searchname)
| sprintf (searchname, "%s.", filename);
...
| #if defined(__CYGWIN__)
| {
| char wpath[MAX_PATH];
| cygwin_conv_to_full_win32_path (searchname, wpath);
| module = LoadLibrary (wpath);
| }
| #else
| module = LoadLibrary (searchname);
| #endif
Does `cygwin_conv_to_full_win32_path' DTRT the right thing on cygwin
managed mounts? (Where The Right Thing[tm] is here defined as: do what
we expect it to :)
Cheers,
Ralf
> $ make CFLAGS='-g2 -Wall -Werror'
> ...
> make[2]: Entering directory `/home/eblake/libtool'
> depbase=`echo libltdl/loaders/loadlibrary.lo | sed
> 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
> if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
> -I. -DHAVE_CONFIG_H -DLT_CONFIG_H='' -DLTDL -I. -I. -Ilibltdl
> -I./libltdl -I./libltdl/libltdl -g2 -Wall -Werror -MT
> libltdl/loaders/loadlibrary.lo -MD -MP -MF "$depbase.Tpo" -c -o
> libltdl/loaders/loadlibrary.lo libltdl/loaders/loadlibrary.c; \
> then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1;
> fi
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I. -DHAVE_CONFIG_H
> "-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl -I./libltdl
> -I./libltdl/libltdl -g2 -Wall -Werror -MT libltdl/loaders/loadlibrary.lo -MD
> -MP -MF libltdl/loaders/.deps/loadlibrary.Tpo -c
> libltdl/loaders/loadlibrary.c -DPIC -o libltdl/loaders/.libs/loadlibrary.o
> libltdl/loaders/loadlibrary.c: In function `vm_open':
> libltdl/loaders/loadlibrary.c:164: warning: implicit declaration of function
> `lt_dlhandle_next'
> make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1
Re: Solaris, combining a bunch of convenience archives
Sorry for the delay.
* Ralf Wildenhues wrote on Thu, Oct 13, 2005 at 09:19:06AM CEST:
>
> The other issue is rather independent of this (sorry for mixing it
> up in the descriptions):
>
> For CVS HEAD, where we use `$CC' to link, all I can think of is setting
> whole_archive_flag_spec=
> so that the compiler driver "sees" the objects, so that it actually
> *invokes* the linker instead of bailing, because it thinks it has
> nothing to give to the linker. See test below.
Here is a testsuite update for Libtool CVS HEAD. It updates the
convenience.at tests to check for this specific bug, the one reported,
and a couple more situations: Test linking against one or more
convenience archives, with none or more additional objects on the
command line, with or without -static, done for all tags. The diff
looks huge, but most of it is pretty dull.
OK to apply? The actual fix for Solaris/CVS HEAD is to follow soon.
Cheers,
Ralf
* tests/convenience.at: Updated to expose more corner cases.
Index: tests/convenience.at
===
RCS file: /cvsroot/libtool/libtool/tests/convenience.at,v
retrieving revision 1.4
diff -u -r1.4 convenience.at
--- tests/convenience.at13 Aug 2005 06:45:36 - 1.4
+++ tests/convenience.at25 Oct 2005 20:42:06 -
@@ -17,184 +17,253 @@
# 02111-1307, USA.
# Test that convenience archives work.
+# for each TAG, test:
+# - adding one or multiple convenience archives
+# - with or without additional objects on the cmdline
AT_SETUP([C convenience archives])
-echo 'int a(void) { return 1; }' > a.c
-echo 'int b(void) { return 2; }' > b.c
-echo 'int c(void) { return 3; }' > c.c
-AT_DATA(main.c,
-[[extern int a(void), b(void), c(void);
-int main(void) { return a() + b() + c() != 6; }
-]])
-
-$LIBTOOL --mode=compile $CC $CFLAGS -c a.c
-$LIBTOOL --mode=compile $CC $CFLAGS -c b.c
-$LIBTOOL --mode=compile $CC $CFLAGS -c c.c
-$LIBTOOL --mode=compile $CC $CFLAGS -c main.c
-$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo
-$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libb.la b.lo
-$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libcee.la c.lo liba.la libb.la
-rpath /notexist
-AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -static -o main_static
main.lo libcee.la],
-[0],[ignore],[ignore])
-AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main.lo libcee.la],
-[0],[ignore],[ignore])
-LT_AT_EXEC_CHECK([./main_static])
-LT_AT_EXEC_CHECK([./main])
+cat >main1.c <main2.c <main3.c < a$i.c
+ $LIBTOOL --mode=compile $CC $CFLAGS -c main$i.c
+ $LIBTOOL --mode=compile $CC $CFLAGS -c a$i.c
+ $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba$i.la a$i.lo
+done
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba12.la liba1.la
liba2.la -rpath /notexist],
+[0],[ignore],[ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba123.la a3.lo
liba1.la liba2.la -rpath /notexist],
+[0],[ignore],[ignore])
+
+conv=
+for i in 1 2 3; do
+ conv=$conv$i
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -static -o main_static
main$i.lo liba$conv.la],
+ [0],[ignore],[ignore])
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main$i.lo
liba$conv.la],
+ [0],[ignore],[ignore])
+ LT_AT_EXEC_CHECK([./main_static])
+ LT_AT_EXEC_CHECK([./main])
+done
AT_CLEANUP
AT_SETUP([C++ convenience archives])
LT_AT_TAG([CXX])
-echo 'int a(void) { return 1; }' > a.cpp
-echo 'int b(void) { return 2; }' > b.cpp
-echo 'int c(void) { return 3; }' > c.cpp
-AT_DATA(main.cpp,
-[[extern int a(void), b(void), c(void);
-int main(void) { return a() + b() + c() != 6; }
-]])
-
-$LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c a.cpp
-$LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c b.cpp
-$LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c c.cpp
-$LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c main.cpp
-$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o liba.la a.lo
-$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o libb.la b.lo
-$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o libcee.la c.lo
liba.la libb.la -rpath /notexist
-AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -static -o
main_static main.lo libcee.la],
-[0],[ignore],[ignore])
-AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o main
main.lo libcee.la],
-[0],[ignore],[ignore])
-LT_AT_EXEC_CHECK([./main_static])
-LT_AT_EXEC_CHECK([./main])
+cat >main1.cpp <main2.cpp <main3.cpp < a$i.cpp
+ $LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c main$i.cpp
+ $LIBTOOL --tag=CXX --mode=compile $CXX $CXXFLAGS -c a$i.cpp
+ $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o liba$i.la a$i.lo
+done
+AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXX
FYI: tagtrace test: skip for older autoconf version
Hi Gary,
* Gary V. Vaughan wrote on Thu, Oct 27, 2005 at 12:00:45PM CEST:
> Ralf Wildenhues wrote:
> >
> >To expose: bootstrap with Autoconf CVS, then put 2.59 only in your PATH,
> >then
> > make check TESTS=tests/tagtrace.test VERBOSE=x TESTSUITE_FLAGS=-V
> >
> >It works the other way round, by the way.
>
> Okay.
Thanks!
> Don't forget the ChangeLog entry though...
Sorry, forgot do add it right away. I've applied the patch below, which
also removes the quotes around $AUTOCONF, so it can have arguments.
This is consistent with how we handle $AUTOCONF in the new testsuite.
Cheers,
Ralf
* tests/tagtrace.test: Allow `$AUTOCONF' to contain arguments.
Skip if the running `autoconf' version is older than the one
used to bootstrap Libtool.
Index: tests/tagtrace.test
===
RCS file: /cvsroot/libtool/libtool/tests/tagtrace.test,v
retrieving revision 1.7
diff -u -r1.7 tagtrace.test
--- tests/tagtrace.test 22 Apr 2005 10:10:30 - 1.7
+++ tests/tagtrace.test 27 Oct 2005 08:57:41 -
@@ -25,18 +25,24 @@
: ${fnord=$srcdir/fnord$$}
-"$AUTOCONF" --version > /dev/null 2>&1 || func_skip "This test requires GNU
Autoconf"
+$AUTOCONF --version > /dev/null 2>&1 || func_skip "This test requires GNU
Autoconf"
if touch $fnord; then
rm $fnord
else
func_skip "This test requires write access to the source tree"
fi
+if ( cd "$srcdir" && $AUTOCONF --trace 'LT_SUPPORTED_TAG:$1' ) 2>&1 >/dev/null
|
+ grep "Autoconf version .*is required" >/dev/null; then
+ func_error "This test requires an Autoconf version at least as new"
+ func_skip "as the one that was used to bootstrap Libtool"
+fi
+
# Abort as soon as something fails.
set -e
# Retrieve the list of tags supported by our main libtool script.
-traced_tags=`cd "$srcdir" && "$AUTOCONF" --trace 'LT_SUPPORTED_TAG:$1'`
+traced_tags=`cd "$srcdir" && $AUTOCONF --trace 'LT_SUPPORTED_TAG:$1'`
test -n "$traced_tags"
Re: Fix LT_WITH_LTDL: AU_ALIAS bug
Hi Stepan, * Stepan Kasal wrote on Tue, Oct 25, 2005 at 01:16:06PM CEST: > On Sat, Sep 10, 2005 at 04:17:52PM +0100, Gary V. Vaughan wrote: > > :-( Can you document in HACKING that because of our use of AU_ALIAS to > > maintain backwards compatibility with earlier libtool interfaces we must > > not use $# in m4. > > actually, I'd prefer if you could put it this way: *snip* Can the Autoconf manual also please _explicitly_ *warn* against using `$#' at all in macros? > [ put in public domain, in case you want to paste it somewhere ;-) ] FYI, public domain is not the same thing as copyright assignment; disclaimer is ok, though. Also FYI: I have applied the patch below to Libtool CVS HEAD. Cheers, Ralf 2005-10-27 Stepan Kasal <[EMAIL PROTECTED]> * HACKING: Update note about use of `$#' in m4 macros. Index: HACKING === RCS file: /cvsroot/libtool/libtool/HACKING,v retrieving revision 1.21 diff -u -r1.21 HACKING --- HACKING 26 Sep 2005 12:21:53 - 1.21 +++ HACKING 27 Oct 2005 13:23:13 - @@ -241,8 +241,11 @@ $ECHO ".." for strings without leading hyphen, $ECHO "X.." | $Xsed otherwise. -* Do not use the number of macro arguments `$#' in public macros; - AU_ALIAS may change it. +* The Autoconf manual says that giving an empty parameter is equivalent + to not giving it at all. (In particular, the Autoconf manual doesn't + explain that "FOO()" is calling macro FOO with one empty parameter.) + To prevent misunderstanding, we should use m4_ifval to check whether + a parameter is empty, and not $# to check for the number of parameters. 9. Abstraction layers in libltdl
Re: bootstrap warning
Hi Albert, * Albert Chin wrote on Thu, Oct 27, 2005 at 11:56:31PM CEST: > On Wed, Oct 26, 2005 at 06:55:11AM -0600, Eric Blake wrote: > > > > - diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null \ > > + diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null 2>/dev/null \ > > Rather than ">/dev/null 2>/dev/null", use ">/dev/null 2>&1". Yep, will change on my next commit. Curious though, is there a non-asthetical reason to do this? Cheers, Ralf
cygwin dlopening backends (was: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff)
Hi Charles, Eric, * Charles Wilson wrote on Thu, Oct 27, 2005 at 01:45:05AM CEST: > Eric Blake wrote: > >> > >>Not quite. On a managed mount, cygwin_conv_to_full_win32_path > >>(searchname, wpath); correctly returns the munged underlying > >>Windows name, but earlier in the code, you appended a trailing > >>dot. Since a managed mount munges the trailing dot, you are > >>now trying to load (for example) "c:\cygwin\managed\libfoo%2E", > >>rather than "c:\cygwin\managed\libfoo.", so the call to LoadLibrary > >>won't see a trailing dot and will thus append an implicit ".dll". > > > >On the other hand, I just had a thought. If you were to wait to > >append the trailing dot until after you have converted to the Windows > >name, this idiom of using a trailing dot to supress implicit .dll should > >then work just fine for using LoadLibrary even inside cygwin managed > >mounts. > > But this still doesn't address the issue of WHY loadlibrary.c code is > specialized for cygwin. Yes, it would be NICE if cygwin libltdl could > be configured to use either dlopen OR loadlibrary OR maybe both with one > as a fallback for the other. But it's hardly necessary: dlopen is the > "official" way to demand-load DLLs on cygwin... Ahh. First, let me thank you for your insightful and very nicely written mail; the thread pointers are very helpful -- it took a while to read through them all. There are several separate issues here: 1) lt_dlhandle_iterate breakage of loadlibrary.c 2) needed dlinterface_free (or maybe _unregister?) including documentation 3) cygwin managed mount fix of loadlibrary.c or remove the cygwin-specific code of loadlibrary.c 4) use either - only dlopen, or - first dlopen, then LoadLibrary on cygwin, or - make the choice configurable I want (3) fixed or the cygwin-specific code removed, depending on (4). Rationale: I dislike broken code, even when unused; if it's just because others might copy and paste from it (which has happened before!). My vote would be to allow users the choice by making it configurable, with the default being to use `dlopen' _only_, for the reasons given in the cited threads. I definitely want GNU libtool 2.0 to be identical to cygwin libtool; after all, that was the point of going through the 1.5 differences. Also, I want the guile and libjava users to be able to use an unmodified libltdl. Patches in addition to the ones provided by Eric, for any of these issues, are welcome. It may take a few days until I have time to work on this or test on a w32 box. [ Note to self: when going back to Peter Ekberg's msvc patches: if they work with cygwin (which I haven't tested so far; only msys), be sure to check that LoadLibrary will be enabled in this case. ] Cheers, Ralf
Re: 304-gary-add-libtool-macro-file-serial-tags.diff
Hi Gary, * Gary V. Vaughan wrote on Thu, Oct 27, 2005 at 03:37:35PM CEST: > I believe this to be the correct fix for the bug uncovered by your > test with openMPI. I've also added a new test batch to save us from > regressing later. Thanks. > Okay to commit? (This is now at the front of my queue btw) Hmm. I've got some questions before answering that one. This patch actually makes several logical changes: - put some ugliness with _lt_pkgdatadir in libtoolize's output instead of replacing AT_DATA with cat >expout < libltdl/m4/argz.m4 |2 > libltdl/m4/ltoptions.m4 |2 > libltdl/m4/ltsugar.m4 |2 > libltdl/m4/ltversion.in |2 > libtoolize.m4sh | 39 +++--- > tests/libtoolize.at | 131 > +++- > 6 files changed, 155 insertions(+), 23 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/argz.m4, libltdl/m4/ltoptions.m4, libltdl/ltsugar.m4, > libltdl/m4/ltversion.in: Add serial number tags, and bump serial > number. > * libtoolize.m4sh: Use the tags to locate the correct serial > numbers when deciding whether to update. > * tests/libtoolize.at: More tests for old-style verbatim copying > of macros into aclocal.m4. > (func_serial): Allow for macro_regex argument to be originating > file name. > (func_serial_update): Use NL2SP to flatten list of extracted > m4_include files. > (func_check_macros): In test mode ($_lt_pkgdatadir is set), output > a hardcoded string that the testsuite can match regardless of the > location of the build tree. > (#Main#): Handle argz.m4 specially like ltdl.m4, so that it isn't > copied unless libltdl is being used. Copy other macro files > according to their tagged serial numbers. *snip* > Index: libtool--devo--1.0/libtoolize.m4sh > === > --- libtool--devo--1.0.orig/libtoolize.m4sh > +++ libtool--devo--1.0/libtoolize.m4sh > @@ -566,6 +566,8 @@ func_serial () > my_serial= > for my_file in `func_included_files "$my_filename"`; do >if test -z "$my_macro_regex" || > + test "$my_filename" = aclocal.m4 || > + test "$my_macro_regex" = `echo "$my_filename" | $SED "$basename"` || > func_grep '^AC_DEFUN(\@<:@'"$my_macro_regex" "$my_file" >then > my_serial=`$SED -e "$my_sed_serial" "$my_file"` > @@ -716,8 +718,15 @@ func_serial_update () > # it has `m4_include([DESTFILE])', so the copy effectively already > # updated `aclocal.m4'. > my_included_files=`func_included_files aclocal.m4` > -case `echo " "$my_included_files" "` in > +case `echo " "$my_included_files" " | $NL2SP` in You can simplify this to either case `echo " $my_included_files " | $NL2SP` in or case `echo " "$my_included_files" "` in In the first case, word splitting will not occur, but NL2SP will help you; in the second case, word splitting will occur on $my_included_files before `echo' is called. The fact that the first resulting word there starts with a space is fine. If there is any shell which fails to do this: which one? > + > + # Skip included files: >*" $my_destfile "*) ;; > + > + # Otherwise compare to aclocal.m4 serial number (func_serial > + # returns 0 for older macro serial numbers before we provided > + # serial tags, so the update message will be correctly given > + # if aclocal.m4 contains an untagged --i.e older-- macro file): >*) > if test -f aclocal.m4; then >func_serial_max \ > @@ -851,7 +860,9 @@ func_check_macros () > func_echo "and rerunning libtoolize." >fi > elif test -z "$m4dir"; then > - if test "$ltdldir/m4" != "$m4dir"; then > + if test -n "$_lt_pkgdatadir"; then > + acmacrodir="\$_lt_pkgdatadir" > + elif $opt_ltdl && test "$ltdldir/m4" != "$m4dir"; then > acmacrodir="$ltdldir/m4" >else > acmacrodir="$aclocaldir" *snip*
Re: 304-gary-add-libtool-macro-file-serial-tags.diff
Hi Gary, * Gary V. Vaughan wrote on Fri, Oct 28, 2005 at 04:11:31PM CEST: > Ralf Wildenhues wrote: > > >This patch actually makes several logical changes: > > ACK. If you'd rather see it as separate commits, I can break it up. > I figured that since they were there to fix a single bug that putting > them in a single patch was okay. I don't mind either way :-D If you don't mind, then separate patches are better; but I see that they are more work, too. They should get reviewed more quickly. :) > >- use that to find out versions in hand-maintained aclocal.m4. > > (Would that work with `acinclude.m4' as well, by the way?) > > Only if m4_include(acinclude.m4) is added to aclocal.m4. acinclude.m4 > doesn't make sense for a hand maintained aclocal.m4 -- either aclocal > manages aclocal.m4 and acinclude.m4 is copied into it, or else aclocal.m4 > is hand maintained, in which case macros will be pasted into aclocal.m4 > directly. > > We could add support for users that hand maintain acinclude.m4 instead > of letting aclocal m4_include local copies of macro files, but use > aclocal to maintain aclocal.m4 proper. There are definitely some odd > corner cases, such as aclocal.m4 not yet generated. But doing that is > a feature: hence, post 2.0. OK. > >- treat argz.m4 like ltdl.m4. This is the most troublesome. > >`aclocal' is actually smart enough not to include argz.m4 in the case > >that libltdl is a subproject, because *then*, the user doesn't actually > >need the argz tests in the toplevel project; but she does need other > >stuff in ltdl.m4. > > But Automake will not distribute argz.m4 for the top-level Makefile.am, > even if it is in AC_CONFIG_MACRO_DIR, unless aclocal uses it. Only ltdl.m4 > uses argz.m4, so it seems odd to treat them differently. However, I'm happy > to commit just the other parts and discuss this issue separately. My point is: Automake and aclocal are both smart enough, yet libtoolize warns. To reproduce, use OpenMPI again, see below. :) > >I get the impression that we are trying to outsmart something which, in > >the end, may just as well break again with the next change in aclocal. > >Why not just tell those users that hand-maintain aclocal.m4 to get their > >act together and take care of keeping it up-to-date themselves. No need > >to try to be any smarter than that. > > Apart from the argz.m4 change, the rest of this patch is only about > asking the user to update some or all of the newly copied libtool m4 > macro files. Just getting the messages right, and nothing else... I know. But the message was bogus: | [Running] /tmp/install/libtool-2.1/bin/libtoolize --automake --copy --ltdl=opal/libltdl | libtoolize: You should add the contents of `./config/argz.m4' to `aclocal.m4'. And as such, I don't think your patch is ok. > >I am somewhat undecided on that matter, and you certainly have more > >experience. What do you think? > >>-case `echo " "$my_included_files" "` in > >>+case `echo " "$my_included_files" " | $NL2SP` in > > > >You can simplify this to either > > case `echo " $my_included_files " | $NL2SP` in > > ACK. I've changed to this format. > > >or > > case `echo " "$my_included_files" "` in > >In the first case, word splitting will not occur, but NL2SP will help > >you; in the second case, word splitting will occur on $my_included_files > >before `echo' is called. The fact that the first resulting word there > >starts with a space is fine. > > Until I added NL2SP, the latter version wasn't matching at all with > bash-2.05b or bash-3.0 on my darwin machine. Weird. What's different at your site? $ foo='a b c' $ f=b $ case `echo " "$foo" "` in *" $f "*) echo yes;; esac yes $ uname -mrs Darwin 8.2.0 Power Macintosh $ echo $BASH_VERSION 2.05b.0(1)-release Cheers, Ralf
Re: workaround for virtualpc bug
Hi Christoph, * Christoph Egger wrote on Fri, Oct 28, 2005 at 03:00:21PM CEST: > > The following condition must be met to reproduce the virtualpc bug: > > - VirtualPC must run in the background or in the dock > - you must link a module and use -export-symbols > - $output_objdir/$libname.filter must be empty Wow. > When the conditions are met and the error appears, then you see > this error: > > Cannot export : symbol not defined > Creating library file: $output_objdir/$libname.dll.a > collect2: ld returned 1 exit status *snip* > The patch works around the bug in virtualpc by not operating > on an empty file. Wouldn't this rather be a bug in sed? > The patch has been reviewed and okey'd by Peter Ekberg (who > originally wrote the piece of code the patch touches). Does this simpler patch also work? Which sed version is this, by the way? Cheers, Ralf Index: libltdl/config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.14 diff -u -r1.14 ltmain.m4sh --- libltdl/config/ltmain.m4sh 17 Oct 2005 14:06:36 - 1.14 +++ libltdl/config/ltmain.m4sh 28 Oct 2005 15:47:40 - @@ -5006,6 +5006,7 @@ # global variables. join(1) would be nice here, but unfortunately # isn't a blessed tool. $opt_dry_run || $SED -e '/[[ ,]]DATA/!d;s,\(.*\)\([[ \,]].*\),s|^\1$|\1\2|,' < $export_symbols > $output_objdir/$libname.filter + test -s $output_objdir/$libname.filter && echo ': dummy' >> $output_objdir/$libname.filter delfiles="$delfiles $export_symbols $output_objdir/$libname.filter" export_symbols=$output_objdir/$libname.def $opt_dry_run || $SED -f $output_objdir/$libname.filter < $orig_export_symbols > $export_symbols
Re: workaround for virtualpc bug
Hi Christoph, * Christoph Egger wrote on Fri, Oct 28, 2005 at 09:56:09PM CEST: > > * Christoph Egger wrote on Fri, Oct 28, 2005 at 03:00:21PM CEST: > > > > > > When the conditions are met and the error appears, then you see > > > this error: > > > > > > Cannot export : symbol not defined > > > Creating library file: $output_objdir/$libname.dll.a > > > collect2: ld returned 1 exit status *snip* > > > The patch works around the bug in virtualpc by not operating > > > on an empty file. > > > > Wouldn't this rather be a bug in sed? > > If this is a bug in sed, why wouldn't it have been catched earlier? Hey, I don't know. Apparently it isn't. > I mean, if it is a sed bug rather one in virtualpc, then there > should be more platforms where this issue is reproducable. > > > > The patch has been reviewed and okey'd by Peter Ekberg (who > > > originally wrote the piece of code the patch touches). > > > > Does this simpler patch also work? > > No, this patch does not work. hmm... so my patch is more likely > to work around a bug in sed than in virtualpc then ...? Likely. > > Which sed version is this, by the way? > > This is GNU sed 4.1.4. OK. I would like to understand the issue before applying your patch: I dislike very much any 'fix' where the issue isn't fully analyzed, for several reasons: there might be other places that need fixing, the issue might be solved easier or more thoroughly in a different way, some other component might need fixing instead of Libtool (or additionally). Could you please find out for me: - whether empty files in general get messed up in your setup - whether newline encoding is the issue - whether the sed -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' outputs something weird. Your patch looks ok otherwise. Cheers, Ralf
Re: [patch 09/19] 293-gary-default-convenience-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 04:34:14PM CEST: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:33PM CEST: > > > >>libltdl/m4/ltdl.m4 |7 +-- > >>1 files changed, 5 insertions(+), 2 deletions(-) > >> > >>Index: libtool--devo--1.0/ChangeLog > >>from Gary V. Vaughan <[EMAIL PROTECTED]> > >>* libltdl/m4/ltdl.m4 (LTDL_INIT): Call _LT_ENABLE_INSTALL directly > >>instead of m4_requiring it, as it relies on enable_ltdl_install > >>and enable_ltdl_convenience to have been initialised first. > > > > > >Why and when can this happen? > > Apply all the patches in the stack leading up to (but not including) > this one, and the AC_REQUIRE tree ends up putting the expansion of > _LT_ENABLE_INSTALL before the code that sets the shell variables it > examines. Yep. :-/ > >We should think about adding a test to check whether `configure' has the > >order correctly here (plus maybe documentation and AC_BEFORE instances > >in case there are ordering issues hidden here); but I'd like to > >understand the problem first. > > That sounds like a good idea, although I don't know how to write that > test :-( Me neither. This patch is ok. Even more, it's needed for 288 which you had higher up in your queue. Please apply this one first, it's necessary for the tests in 288 to pass. Cheers, and thanks! Ralf
Re: [patch 05/19] 288-gary-ltdl-nonrecursive-tests.diff Queue
Ho Gary, * Gary V. Vaughan wrote on Fri, Oct 14, 2005 at 05:30:39PM CEST: > Ralf Wildenhues wrote: > >See nits below, and this one: all of them FAIL with 2.59/1.9.6 (without > >libobjdir fixes): > > > >[...] > >| configure.ac:11: required file `./lt__dirent.c' not found > >| configure.ac:11: required file `./argz.c' not found > >| configure.ac:11: required file `./lt__strl.c' not found > >| Makefile.am: installing `libltdl/config/depcomp' > >| autoreconf: automake failed with exit status: 1 > > > >Can you make them SKIP in this case, so we don't get oodles of bogus bug > >reports? > > No need. Fixed the tests to work irrespective of SUBDIR_LIBOBJS support. Great, thanks. Guess we need to document this (version requirement and/or workaround). > >>and surely AC_PROG_CC should come before AM_INIT_AUTOMAKE? > > > >Not at all, why? INIT sounds like: do this first. Right? > >Sounds right to me. Everything that has to become before this _needs_ > >to be documented very explicitly. Quoting automake.info (Complete): > > Done. Merci. > Okay to commit? Yes, please, after addressing these two nits: - accommodate for Makefile.inc changes (AM_CPPFLAGS and AM_LDFLAGS) - having installed 293 first. Thanks! Ralf > Makefile.am |1 > tests/nonrecursive.at | 150 > ++ tests/testsuite.at| > 9 +++ > 3 files changed, 160 insertions(+) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * tests/nonrecursive.at: New tests for libltdl as a subdirectory, > configured and compiled from the toplevel project. > * tests/testsuite.at: Use it. > (LT_AT_AUTOHEADER): New macro. > * Makefile.am (TESTSUITE_AT): Depend on nonrecursive.at.
Re: workaround for virtualpc bug
Hi Christoph, * Christoph Egger wrote on Sat, Oct 29, 2005 at 01:20:00AM CEST: > > > > Could you please find out for me: > > - whether empty files in general get messed up in your setup > > - whether newline encoding is the issue > > - whether the > >sed -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' > > outputs something weird. > > I created a small script, which tests all these cases. > If it is really a sed bug, then it should reproduce the issue. So, does it reproduce the issue now? :) Can you see which part is at fault? Cheers, Ralf
Re: [patch 12/19] 296-gary-ltdl-recursive-tests.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:36PM CEST: > Makefile.am|1 > tests/recursive.at | 108 > + > tests/testsuite.at |2 > 3 files changed, 111 insertions(+) OK after preliminaries are in, and addressing these two nits: - `touch foo.c' is forbidden :) - can you use `ltdl' as the subdir throughout? It tests the fact that `recursive' mode works with a different name. No need to change the arguments to `libtoolize', by the way (backward compatibility!) Thank you! Cheers, Ralf > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * tests/recursive.at: New tests for libltdl as a subdirectory, > configured and compiled from the toplevel project using a > recursive make.. > * tests/testsuite.at: Use it. > * Makefile.am (TESTSUITE_AT): Depend on it. *snip*
libtoolize --ltdl non-failure (was: [O-MPI devel] ppc64 linux bustage?)
[ This is a bug reported against Debian libtool/libltdl packages, uncovered in OpenMPI; see here: http://www.open-mpi.org/community/lists/devel/2005/10/0487.php It affects Debian packages, Libtool CVS branch-1-5, and CVS HEAD. For followups, please remove [EMAIL PROTECTED] (subscribers only). ] > * Troy Benjegerdes wrote on Sat, Oct 29, 2005 at 08:01:08AM CEST: > [ reported this: ] * Ralf Wildenhues wrote on Sat, Oct 29, 2005 at 10:38:11AM CEST: > It's a bug when > libtoolize --ltdl > succeeds although it did not find the libltdl source files. To reproduce: uninstall libtldl3-dev on Debian, then see above command still succeeding; alternatively, just move `$pkgdatadir/libltdl' somewhere else after `make install'. I'm uncertain whether Debian's packaging needs a change, though. In any case, OK to apply the patch below to branch-1-5? Gary, could you look into a fix for CVS HEAD? The corresponding code looks a bit nonobvious to me. Cheers, Ralf * libtoolize.in: Fail if libltdl files not present but `--ltdl' given. Reported by Troy Benjegerdes <[EMAIL PROTECTED]>. Index: libtoolize.in === RCS file: /cvsroot/libtool/libtool/Attic/libtoolize.in,v retrieving revision 1.21.2.13 diff -u -r1.21.2.13 libtoolize.in --- libtoolize.in 22 Apr 2005 09:05:40 - 1.21.2.13 +++ libtoolize.in 29 Oct 2005 09:01:33 - @@ -281,6 +281,10 @@ if test "x$ltdl" = xyes; then test -d libltdl || $mkdir libltdl ltdlfiles=`cd $pkgdatadir && ls libltdl/*` + if test -z "$ltdlfiles"; then +echo "$progname: cannot list files in \`$pkgdatadir/libltdl'" 1>&2 +exit 1 + fi else ltdlfiles= fi
Re: libtoolize --ltdl non-failure
Hi Peter, * Peter O'Gorman wrote on Sat, Oct 29, 2005 at 01:55:53PM CEST: > Ralf Wildenhues wrote: > | In any case, OK to apply the patch below to branch-1-5? > > Yes, this is fine. Thank you. Thanks. Applied (branch-1-5). Cheers, Ralf > | * libtoolize.in: Fail if libltdl files not present but > | `--ltdl' given. > | Reported by Troy Benjegerdes <[EMAIL PROTECTED]>.
Re: ITS#3977 libtool 1.5.18 and installed libraries
Hello again,
* Ralf Wildenhues wrote on Sun, Sep 25, 2005 at 01:14:57PM CEST:
>
> Sorry for the long response delay.
If I may repeat that.. :-/
Applied to CVS HEAD and branch-1-5, respectively.
Cheers, and sorry again,
Ralf
2005-10-29 Howard Chu <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh (func_mode_link):
With `-static', only link statically against uninstalled
libtool libraries. Fixes 1.5.x regression to match documented
behavior.
* NEWS: Updated.
2005-10-29 Howard Chu <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh (func_mode_link):
With `-static', only link statically against uninstalled
libtool libraries. Fixes 1.5.x regression to match documented
behavior.
* NEWS: Updated.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.187
diff -u -r1.187 NEWS
--- NEWS26 Oct 2005 10:42:03 - 1.187
+++ NEWS29 Oct 2005 14:17:14 -
@@ -26,6 +26,8 @@
* Detection of compiler wrappers like distcc/ccache and $host_alias prefix.
* Initial Support for FC (modern Fortran).
* Fixed a regression that prevented use of libltdl without autotools.
+* Fixed a branch-1-5/HEAD regression to only link uninstalled libraries
+ statically with `-static'.
* Bug fixes.
New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.14
diff -u -r1.14 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 17 Oct 2005 14:06:36 - 1.14
+++ libltdl/config/ltmain.m4sh 29 Oct 2005 14:17:16 -
@@ -2218,14 +2218,15 @@
compile_command="$compile_command $link_static_flag"
finalize_command="$finalize_command $link_static_flag"
fi
+ prefer_static_libs=yes
else
if test -z "$pic_flag" && test -n "$link_static_flag"; then
dlopen_self=$dlopen_self_static
fi
+ prefer_static_libs=built
fi
build_libtool_libs=no
build_old_libs=yes
- prefer_static_libs=yes
break
;;
esac
@@ -3598,8 +3599,12 @@
fi
link_static=no # Whether the deplib will be linked statically
+ use_static_libs=$prefer_static_libs
+ if test "$use_static_libs" = built && test "$installed" = yes; then
+ use_static_libs=no
+ fi
if test -n "$library_names" &&
- { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+ { test "$use_static_libs" = no || test -z "$old_library"; }; then
case $host in
*cygwin* | *mingw*)
# No point in relinking DLLs because paths are not encoded
2005-10-29 Howard Chu <[EMAIL PROTECTED]>
* ltmain.in (link mode): With `-static', only link statically
against uninstalled libtool libraries. Fixes 1.5.x regression
to match documented (and actual 1.4.x) behavior.
* NEWS: Updated.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.109.2.36
diff -u -r1.109.2.36 NEWS
--- NEWS31 Aug 2005 19:19:41 - 1.109.2.36
+++ NEWS29 Oct 2005 14:17:57 -
@@ -1,6 +1,9 @@
NEWS - list of user-visible changes between releases of GNU Libtool
New in 1.5.21a: 2005-??-??; CVS version 1.5.21a, Libtool team:
+* Fix 1.5 regression that caused linking a program `-static' to also
+ link statically against installed libtool libraries, contrary to
+ documented (and actual 1.4.x) behavior.
* Bug Fixes.
New in 1.5.20: 2005-08-31; CVS version 1.5.19a, Libtool team:
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.91
diff -u -r1.334.2.91 ltmain.in
--- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91
+++ ltmain.in 29 Oct 2005 14:17:59 -
@@ -1088,14 +1088,15 @@
if test -n "$link_static_flag"; then
dlopen_self=$dlopen_self_static
fi
+ prefer_static_libs=yes
else
if test -z "$pic_flag" && test -n "$link_static_flag"; then
dlopen_self=$dlopen_self_static
fi
+ prefer_static_libs=built
fi
build_libtool_libs=no
build_old_libs=yes
- prefer_static_libs=yes
break
;;
esac
@@ -2445,8 +2446,12 @@
fi
link_static=no # Whether the deplib will be linked statically
+ use_static_libs=$prefer_st
Re: [patch 09/19] 293-gary-default-convenience-ltdl.diff Queue
* Ralf Wildenhues wrote on Fri, Oct 28, 2005 at 10:52:22PM CEST: > > >* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:33PM CEST: > > > > > >>Index: libtool--devo--1.0/ChangeLog > > >>from Gary V. Vaughan <[EMAIL PROTECTED]> > > >> * libltdl/m4/ltdl.m4 (LTDL_INIT): Call _LT_ENABLE_INSTALL directly > > >> instead of m4_requiring it, as it relies on enable_ltdl_install > > >> and enable_ltdl_convenience to have been initialised first. > > This patch is ok. Mind this typo, though: | +dnl Don't require this, or it will be expanded earlier that the code s/that/than | +dnl that sets the variables it relies on: | +_LT_ENABLE_INSTALL Thanks, Ralf
Re: [patch 06/19] 289-gary-LT_WITH_LTDL-nonrecursive.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:30PM CEST:
> configure.ac |1
> libltdl/m4/ltdl.m4 | 65
> +
> 2 files changed, 47 insertions(+), 19 deletions(-)
>
> Index: libtool--devo--1.0/ChangeLog
> from Gary V. Vaughan <[EMAIL PROTECTED]>
> * libltdl/m4/ltdl.m4 (LT_CONFIG_LTDL_DIR): Add LTDL-MODE
> argument.
> * configure.ac: Use it.
OK after addressing nits below. Thank you!
Cheers,
Ralf
> Index: libtool--devo--1.0/configure.ac
> ===
> --- libtool--devo--1.0.orig/configure.ac
> +++ libtool--devo--1.0/configure.ac
> @@ -27,6 +27,7 @@ dnl Oldest automake required for bootstr
> AC_INIT([libtool], [2.1a], [EMAIL PROTECTED])
> AC_CONFIG_HEADERS([config.h:config-h.in])
> AC_CONFIG_SRCDIR([libtoolize.in])
> +LT_CONFIG_LTDL_DIR([libltdl], [nonrecursive])
> AC_CONFIG_AUX_DIR([libltdl/config])
> AC_CONFIG_MACRO_DIR([libltdl/m4])
> AC_CONFIG_LIBOBJ_DIR([libltdl])
> Index: libtool--devo--1.0/libltdl/m4/ltdl.m4
> ===
> --- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4
> +++ libtool--devo--1.0/libltdl/m4/ltdl.m4
> @@ -7,8 +7,8 @@
>
> # serial 9 LTDL_INIT
>
> -# LT_CONFIG_LTDL_DIR(DIRECTORY)
> -# -
> +# LT_CONFIG_LTDL_DIR(DIRECTORY, [LTDL-MODE])
> +# --
> # DIRECTORY contains the libltdl sources. It is okay to call this
> # function multiple times, as long as the same DIRECTORY is always given.
> AC_DEFUN([LT_CONFIG_LTDL_DIR],
> @@ -31,10 +31,16 @@ m4_case(_LTDL_DIR,
> [],
> [m4_fatal([multiple libltdl directories: `]_LTDL_DIR[',
> `]_ARG_DIR['])])])
> m4_popdef([_ARG_DIR])
> -])
> +dnl If not otherwise defined, default to the 1.5.x compatible subproject
> mode:
> +m4_if(_LTDL_MODE, [],
> + [m4_define([_LTDL_MODE], m4_default([$2], [subproject]))
> + m4_if([-1], [m4_bregexp(_LTDL_MODE, [\(subproject\|nonrecursive\)])],
> + [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])])
Make this an m4_fatal instead of AC_MSG_ERROR, no need to defer the
error until configure time.
> +])# LT_CONFIG_LTDL_DIR
>
> # Initialise:
> m4_define([_LTDL_DIR], [])
> +m4_define([_LTDL_MODE], [])
>
>
> # LTDL_CONVENIENCE
> @@ -138,6 +144,23 @@ dnl aclocal-1.4 backwards compatibility:
> dnl AC_DEFUN([AC_LIBLTDL_INSTALLABLE], [])
>
>
> +# _LTDL_MODE_DISPATCH
> +# ---
> +m4_define([_LTDL_MODE_DISPATCH],
> +[dnl If _LTDL_DIR is `.', then we are configuring libltdl itself:
> +m4_if(_LTDL_DIR, [],
> + [],
> +dnl if _LTDL_MODE was not set already, the default value is `subproject':
> +[m4_case(m4_default(_LTDL_MODE, [subproject]),
> + [subproject], [AC_CONFIG_SUBDIRS(_LTDL_DIR)
> + _LT_SHELL_INIT([lt_dlopen_dir="$lt_ltdl_dir"])],
> + [nonrecursive], [_LT_SHELL_INIT([lt_dlopen_dir="$lt_ltdl_dir"])],
> + [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])])dnl
Ditto.
> +dnl Be careful not to expand twice:
> +m4_define([$0], [])
> +])# _LTDL_MODE_DISPATCH
> +
> +
> # LT_WITH_LTDL([LTDL-MODE])
> # -
> # Clients of libltdl can use this macro to allow the installer to
> @@ -195,13 +218,14 @@ fi
> AC_MSG_CHECKING([whether to use included libltdl])
> AC_MSG_RESULT([$with_included_ltdl])
>
> -AC_CONFIG_SUBDIRS(_LTDL_DIR)
> -
> -dnl Be certain that LTDL_INIT is invoked:
> -AC_PROVIDE_IFELSE([LTDL_INIT],
> - [],
> -[LTDL_INIT
> -AC_DEFUN([LTDL_INIT], [])])
> +dnl Be certain that LTDL_INIT is invoked if we are configuring libltdl
> +dnl from here:
> +m4_if(_LTDL_MODE, [subproject],
> + [_LTDL_MODE_DISPATCH],
> +[AC_PROVIDE_IFELSE([LTDL_INIT],
> + [],
> + [LTDL_INIT
> + AC_DEFUN([LTDL_INIT], [])])])
> ])# LT_WITH_LTDL
>
> # Old name:
> @@ -245,6 +269,9 @@ m4_provide_if([_LT_CONFIG_LTDL_DIR],
> [m4_ifval([$1], [_LT_CONFIG_LTDL_DIR([$1])])],
> [_LT_CONFIG_LTDL_DIR(m4_default([$1], [libltdl]))])dnl
>
> +dnl _LTDL_MODE specific code must be evaluated at least once:
> +_LTDL_MODE_DISPATCH
> +
> # In order that ltdl.c can compile, run AC_CONFIG_HEADERS for the user
> # if they did not call it themself. This is so that ltdl.h can pick up
> # the parent projects config.h file, The first file in AC_CONFIG_HEADERS
> @@ -481,7 +508,7 @@ AC_CHECK_LIB([dl], [dlopen],
> [AC_DEFINE([HAVE_LIBDL], [1],
> [Define if you have the libdl library or equivalent.])
> LIBADD_DLOPEN="-ldl" libltdl_cv_lib_dl_dlopen="yes"
> - LT_DLLOADERS="$LT_DLLOADERS ${lt_ltdl_dir+$lt_ltdl_dir/}dlopen.la"],
> + LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"],
> [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#if HAVE_DLFCN_H
> # include
> #endif
> @@ -489,12 +516,12 @@ AC_CHECK_LIB([dl], [dlopen],
> [AC_DEFINE([HAVE_
FYI: Remove duplicate settion of archive_expsym_cmds=yes on AIX
Hi Albert,
* Albert Chin wrote on Mon, Oct 31, 2005 at 07:18:40AM CET:
> always_export_symbols is set before the if statement enclosing the
> code below so remove duplicates.
>
> Patch against branch-1-5.
Thanks. Applied, and also the following to HEAD.
Cheers,
Ralf
2005-10-31 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
[ aix ]: Remove duplicate always_export_symbols=yes for AIX.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.27
diff -u -r1.27 libtool.m4
--- libltdl/m4/libtool.m4 13 Oct 2005 13:22:55 - 1.27
+++ libltdl/m4/libtool.m4 31 Oct 2005 08:36:33 -
@@ -4165,8 +4165,6 @@
# -berok will link without error, but may produce a broken library.
_LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_TAGVAR(archive_cmds_need_lc, $1)=yes
@@ -5161,8 +5159,6 @@
# -berok will link without error, but may produce a broken library.
_LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_TAGVAR(archive_cmds_need_lc, $1)=yes
Re: Several patches for SCO platform support and other bugfixes
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:00:07AM CET: > > Each patch has a ChangeLog entry and a rationale. I did try to > subscribe to the patches mailing list but I dont know how the > list is set up. I havent received confirmation email, or > subscription may be moderated, so if you have any comments, > please include me directory on the To: line.
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Hi Kean, This time including useful content (sorry!). * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:02:28AM CET: > > OpenServer ships by default with a command line length of 100K, but > the kernel tunable files are not world-readable, so we cannot detect > the dynamic value. So, for OSR5, set the value to 100K. If we don't, > every time libtool is invoked, we get a kernel warning telling us that > the max command line length table was exceded, and the auto-detect > mechanism gets a pessimistically low value (it stops at 32K). On > UnixWare and OpenServer 6, the kernel tunable file *is* world readable > so we check the real value. If it wasnt tuned by the user the default > is a lowly 32K. So I guess we don't want to see the read failure error from grep, since we deal with it. This slightly simpler patch should work as well, with sed being greedy. OK? Cheers, Ralf > 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> > > * libtool.m4(AC_LIBTOOL_SYS_MAX_CMD_LEN): Set correctly for SCO. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.116 diff -u -r1.314.2.116 libtool.m4 --- libtool.m4 31 Oct 2005 08:38:50 - 1.314.2.116 +++ libtool.m4 31 Oct 2005 09:09:16 - @@ -738,6 +738,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null` +if test -n "$kargmax"; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'` +else + lt_cv_sys_max_cmd_len=32768 +fi +;; *) # If test is not a shell built-in, we'll probably end up computing a # maximum length that is only half of the actual maximum length, but
FYI: SCO/bugfix patch 2 of 10: ltmain.in dlopen_deplibs
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:03:26AM CET: > Patch 2 of 10 attached ... > Rationale: > All SCO platforms open dependency libraries when you dlopen a module. OK. Applied to branch-1-5 and HEAD (shown below), although I exchanged your proposed ChangeLog entry with the description above, which I think is much better. :) FYI: in order to conform to our ChangeLog entry format, I'll add this: [ sysv5*, sco3.2v5*, sco5v6*, unixware*, OpenUNIX*, sysv4*uw2* ] Patches for various bug fixes, small improvements and updating the SCO platform support. at the top of the last commit, and also add the THANKS entry which will remove Gary from the second place in the list. :-> Cheers, Ralf 2005-10-31 Kean Johnston <[EMAIL PROTECTED]> * libltdl/m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS): All SCO platforms open dependency libraries when you dlopen a module. Index: libltdl/m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v retrieving revision 1.15 diff -u -r1.15 ltdl.m4 --- libltdl/m4/ltdl.m4 14 Oct 2005 15:43:08 - 1.15 +++ libltdl/m4/ltdl.m4 31 Oct 2005 09:41:15 - @@ -361,6 +361,9 @@ solaris*) lt_cv_sys_dlopen_deplibs=yes ;; + sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*) +libltdl_cv_sys_dlopen_deplibs=yes +;; esac ]) if test "$lt_cv_sys_dlopen_deplibs" != yes; then
Re: SCO/bugfix patch 9 of 10: AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:07:59AM CET: > Patch 9 of 10 attached ... > Rationale: > The valid symbol tags were incorrect for SCO platforms. Correct them. Applied to branch-1-5 and HEAD (below). Thanks! Ralf 2005-10-31 Kean Johnston <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Set correct symcode values for the native nm on SCO platforms. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.28 diff -u -r1.28 libtool.m4 --- libltdl/m4/libtool.m4 31 Oct 2005 08:37:26 - 1.28 +++ libltdl/m4/libtool.m4 31 Oct 2005 09:57:07 - @@ -3040,8 +3040,17 @@ osf*) symcode='[[BCDEGQRST]]' ;; -solaris* | sysv5*) +solaris*) symcode='[[BDRT]]' + ;; +sco3.2v5*) + symcode='[[DT]]' + ;; +sysv4.2uw2*) + symcode='[[DT]]' + ;; +sysv5* | sco5v6* | unixware* | OpenUNIX*) + symcode='[[ABDT]]' ;; sysv4) symcode='[[DFNSTU]]'
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
Hi Kean,
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:04:01AM CET:
> Rationale:
> The test for being able to dlopen yourself is flawed. It was using
> $link_static_flag, which is only present in the generated libtool.
OMG, flawed it truly is. Good catch!
> During autoconfiscation, the variable is called $lt_prog_compiler_static.
> This was causing false positives becuase -Bstatic/-static were not being
> passed through to the link editor, and thus we were actually testing
> a dynamic a.out. Since $lt_prog_compiler_static most likely uses $wl,
> ensure that wl is set to $lt_prog_compiler_wl before running the test,
> so that $lt_prog_compiler_static expands correctly.
Your fix isn't correct, as there needs to be one more expansion level,
so that the compiler won't see ${wl}, but its variable expansion. Also,
I'd like to avoid cluttering namespace.
we use $lt_prog_compiler_static wrongly in one more place. Also, while
looking at this I happened to stumble over a couple of wrong variables
that presumably used to be used instead of ${wl} (?).
My current version of this patch is shown below. Not checking it in
yet; it affects all systems and needs a bit more testing (for example,
on my GNU/Linux system the test will fail), and checking that $wl does
not need to be set/expanded in more places.
Cheers,
Ralf
2005-10-31 Kean Johnston <[EMAIL PROTECTED]>,
Ralf Wildenhues <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_DLOPEN_SELF): Use
`lt_prog_compile_static', not `link_static_flag'. Expand `$wl'
so expansion of `export_dynamic_flag_spec' works.
(AC_LIBTOOL_PROG_LD_SHLIBS) [ aix3 ]: Likewise.
(AC_LIBTOOL_PROG_COMPILER_PIC) [ hpux* ]: Use `${wl}'.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.117
diff -u -r1.314.2.117 libtool.m4
--- libtool.m4 31 Oct 2005 09:59:15 - 1.314.2.117
+++ libtool.m4 31 Oct 2005 11:32:45 -
@@ -949,7 +949,7 @@
])
if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
+ LDFLAGS=$LDFLAGS\ `wl=$lt_prog_compiler_wl eval echo
"$lt_prog_compiler_static"`
AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
lt_cv_dlopen_self_static, [dnl
_LT_AC_TRY_DLOPEN_SELF(
@@ -4850,14 +4850,14 @@
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test "$host_cpu" != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
case $host_cpu in
hppa*64*|ia64*)
# +Z the default
@@ -5516,7 +5516,7 @@
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
Re: SCO/bugfix patch 4 of 10: ltmain.in rpath variable
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:04:42AM CET: > > On SCO platforms it is very important to be able to create shared > libaries with absolute SONAME entries, and to have executables that > use those hard-coded names and not rely on DT_RUNPATH. The problem is > that only relatively recent versions of the OS had protection in the > RTLD against using LD_LIBRARY_PATH with elevated priveliges. Being > able to divert a library in a program with elevated priveliges is a > huge security risk. So the SCO patch (see next mail) provides the > facility to set absolute path names in shared libraries if the > environment variable `SCOABSPATH' is non-empty. In order for this to > work, libtool needs to know what the installation path of the shared > library is going to be. This is the value of -rpath. The problem with > the current mechanism is that -rpath accumulates args, and adds spaces. > I don't know if specifying multiple -rpath's has meaning to any platform, > so to be on the safe side, rather than making rpath be a non-accumulating > variable, I introduce a new variable called 'instrpath' that is set to > whatever the last -rpath argument was. Aren't you looking for install_libdir? If yes, this patch is not needed (and discussion can be deferred until the other patch, the one that uses it). Also note that it picks up the first `-rpath' argument given, not the last one. Cheers, Ralf *snip* > 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> > > * ltmain.in: Set a non-accumulating installation > rpath variable to facilitate setting absolute paths in shared > libraries. *snip*
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
* Ralf Wildenhues wrote on Mon, Oct 31, 2005 at 01:14:30PM CET:
> * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:04:01AM CET:
>
> > The test for being able to dlopen yourself is flawed. It was using
> > $link_static_flag, which is only present in the generated libtool.
>
> Your fix isn't correct, as there needs to be one more expansion level,
> so that the compiler won't see ${wl}, but its variable expansion. Also,
> I'd like to avoid cluttering namespace.
It's even worse, plain `echo' might not like the hyphen as first
character. Next try:
> 2005-10-31 Kean Johnston <[EMAIL PROTECTED]>,
> Ralf Wildenhues <[EMAIL PROTECTED]>
>
> * libtool.m4 (AC_LIBTOOL_DLOPEN_SELF): Use
> `lt_prog_compile_static', not `link_static_flag'. Expand `$wl'
> so expansion of `export_dynamic_flag_spec' works.
> (AC_LIBTOOL_PROG_LD_SHLIBS) [ aix3 ]: Likewise.
> (AC_LIBTOOL_PROG_COMPILER_PIC) [ hpux* ]: Use `${wl}'.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.117
diff -u -r1.314.2.117 libtool.m4
--- libtool.m4 31 Oct 2005 09:59:15 - 1.314.2.117
+++ libtool.m4 31 Oct 2005 15:57:40 -
@@ -949,7 +949,7 @@
])
if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
+ LDFLAGS=$LDFLAGS`wl=$lt_prog_compiler_wl eval echo \"
$lt_prog_compiler_static\"`
AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
lt_cv_dlopen_self_static, [dnl
_LT_AC_TRY_DLOPEN_SELF(
@@ -4850,14 +4850,14 @@
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test "$host_cpu" != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
case $host_cpu in
hppa*64*|ia64*)
# +Z the default
@@ -5020,7 +5020,7 @@
[
if test "$GCC" = yes; then
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-static'
case $host_os in
aix*)
@@ -5516,7 +5516,7 @@
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
Re: About the use of ${wl} ...
* Kean Johnston wrote on Mon, Oct 31, 2005 at 05:00:40PM CET:
>
> If you find youself having to make changes to things that
> use ${wl}, consider consolidating the arguments. It makes some
> long lines a bit shorter, and can read better. -Wl takes any
> number of comma-separated arguments and expands them out
> correctly when invoking the link editor. So instead of:
>
> some_variable="${wl}-h ${wl}$soname"
>
> you can use:
>
> some_variable="${wl}-h,$soname"
Are you speaking of arguments given to `libtool' or given to `$CC'?
If the latter: AFAIK not every compiler allows aggregation of arguments
after its variant of $wl. `libtool' OTOH copes fine with
./libtool --mode=link gcc -Wl,-foo,-bar,-baz ...
> Although there are no cases I have seen thus far that would be
> affected, this is also a bit safer, as it guarantees that the
> correct arguments travel with the correct options. At least at
> one point in its lifetime, libtool would rewrite command lines
> and if you happen to split along the incorrect boundary you
> could land in a world of trouble.
Ok, so you are speaking about `libtool'. Well, please report any
cases where you see this.
OTOH, some compiler drivers reorder as well. Last bug report entered
bug-libtool a few hours ago.
> Like I said, its just cosmetic, but then my brain was compiled
> with -pedantic :)
Pedantic is necessary for libtool, if you want to keep it from breaking.
Cheers,
Ralf
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
* Kean Johnston wrote on Mon, Oct 31, 2005 at 05:20:20PM CET: > > For the sake of legibility, how about: > sflag=`wl=$lt_prog_compiler_wl eval echo " $lt_prog_compiler_static "` > LDFLAGS="$LDFLAGS $sflag" > > This way you avoid the escaping of the quotes and the not-so-obvious > concatenation of strings in the LDFLAGS assignment. You have to escape the quotes. Your example above won't work always: lt_prog_compiler_static may begin with `-n': lt_prog_compiler_static=-non-shared `echo' may interpret `-n'. Boom. Prepending `echo's first argument with a space fixes that. > 'sflag' intentionally kept to a short name so that Thunderbird > doesnt wrap the lines above. Yeah, I guess a helper variable would be ok. Cheers, Ralf
FYI: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Hi Kean, Tim, * Kean Johnston wrote on Mon, Oct 31, 2005 at 04:28:11PM CET: > Yes your simplified sed looks fine. Thanks! * Tim Rice wrote on Mon, Oct 31, 2005 at 07:14:27PM CET: > On Mon, 31 Oct 2005, Ralf Wildenhues wrote: > > > [snip] > > So I guess we don't want to see the read failure error from grep, since > > we deal with it. This slightly simpler patch should work as well, with > > sed being greedy. OK? > > Tests fine here. Thanks. Applied to branch-1-5 as shown, and CVS HEAD as below. Cheers, Ralf 2005-10-31 Kean Johnston <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Set correctly for SCO. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.29 diff -u -r1.29 libtool.m4 --- libltdl/m4/libtool.m4 31 Oct 2005 09:58:38 - 1.29 +++ libltdl/m4/libtool.m4 31 Oct 2005 18:52:38 - @@ -1378,6 +1378,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null` +if test -n "$kargmax"; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'` +else + lt_cv_sys_max_cmd_len=32768 +fi +;; *) # Make teststring a little bigger before we do anything with it. # a 1K string should be a reasonable start.
Re: About the use of ${wl} ...
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 06:03:06PM CET: > >Are you speaking of arguments given to `libtool' or given to `$CC'? > $CC OK. > >If the latter: AFAIK not every compiler allows aggregation of > >arguments after its variant of $wl. > Ah. I thought it was pretty universal. If not then just ignore > the suggestion. But I checked Irix, Solaris, HP-UX 10, HP-UX 11, > Tru64 (and OSF/1), and of course any OS that uses GCC as its > compiler. Also checked icc. They all do agregation. If even > *IRIX* does it ... :) Well, we might consider changing that, if we find no compiler that disobeys this rule; I don't *know* offhand of a counter example, to be honest. We'd just need to check all Fortran, C, C++, compilers, gcj, Portland, IBM. Besides the OSes you mentioned, all w32 are missing; since a msvc update is pending, that one should work as well, also windres. Also a couple of rarer used ones, plus of course a bit older releases. So, do you still think this holds everywhere? Cheers, Ralf
Re: [1/3] 304-gary-add-libtool-macro-file-serial-tags.diff
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 31, 2005 at 05:11:01PM CET: > > libltdl/m4/argz.m4 |2 +- > libltdl/m4/ltoptions.m4 |2 +- > libltdl/m4/ltsugar.m4 |2 +- > libltdl/m4/ltversion.in |2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libltdl/m4/argz.m4, libltdl/m4/ltoptions.m4, libltdl/ltsugar.m4, > libltdl/m4/ltversion.in: Add serial number tags, and bump serial > number. Well, the patch doesn't have any obvious flaws, but on its own, it doesn't have too much of a point, either, right? :-) Cheers, Ralf
Re: SCO/bugfix patch 10 of 10: --version-info improvement
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:08:33AM CET: > > I have encountered at least two applications so far that do a realpath() > on a shared library, and then check the SONAME to ensure that they match > a compile-time constant. I know, the applications are retarded. Yes. Very retarded. Please file bugs with them. > But > libtool is a program that is supposed to make creating shared libraries > easier, and having the ability to actually have control over things like > the SONAME make it more generically useful, and caters for situations > that we may not have forseen. The current scheme uses soname_spec as the > sole mechanism for setting the SONAME for a shared library. This is > a calculated name based on the current library version. However, as > a programmer, I may know that even though shared library version Y > has some incompatible interfaces relative to version X, that those > chages are a pure superset of X. *snip* I can only agree with Christoph here, that this overlaps with Keith Packard's proposed patch. If you have (too) much spare energy, ;) you can try to get his latest version working decently on w32 systems, AIX (or at least degrade gracefully), and there'll be a good chance of it going in right after 2.0. Oh, and for modules it may be nice, too (optionally). ;-) Cheers, Ralf > 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> > > * ltmain.in: Provide a mechanism for explicitly setting the value > of SONAME in a shared library using an optional 4th argument to > --version-info. > > * doc/libtool.texi: Document it. *snip*
glibc and dlopen self static (was: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF)
* Kean Johnston wrote on Mon, Oct 31, 2005 at 06:14:27PM CET:
>
> So getting back to an actual bit of libtool code, we could have:
>
> sflag=`wl=$lt_prog_compiler_wl eval echo \"$lt_prog_compiler_static\"`
> LDFLAGS="$LDFLAGS $sflag"
Let's just go a different, simpler route:
wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
Similarly to a few lines above the offending snippet.
I have a completely different set of questions now: Why in the world is
that test executable (changed as below) giving me
| /opt/intel_cc_80/lib/: cannot read file data: Is a directory
when I try to dlopen(0, ..), whereas dlopen("./conftest", ..) gives me
| ./conftest: cannot dynamically load executable
on GNU/Linux, glibc-2.3.2 (Debian sarge)? Hmm, when I unset
LD_LIBRARY_PATH, the former becomes
| /lib/: cannot read file data: Is a directory
instead. Bug in dlopen/dlerror?
Cheers,
Ralf
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.118
diff -u -r1.314.2.118 libtool.m4
--- libtool.m4 31 Oct 2005 18:54:20 - 1.314.2.118
+++ libtool.m4 1 Nov 2005 04:21:09 -
@@ -854,6 +854,8 @@
else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
/* dlclose (self); */
}
+ else
+puts (dlerror ());
exit (status);
}]
@@ -960,7 +962,7 @@
])
if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
+ wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS
$lt_prog_compiler_static\"
AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
lt_cv_dlopen_self_static, [dnl
_LT_AC_TRY_DLOPEN_SELF(
@@ -4861,14 +4857,14 @@
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test "$host_cpu" != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
case $host_cpu in
hppa*64*|ia64*)
# +Z the default
@@ -5527,7 +5523,7 @@
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
more macro cleanup: AC_LIBTOOL_DLOPEN_SELF
While working on Kean's third patch, I noticed more (harmless) bogosity: AC_LIBTOOL_DLOPEN_SELF need only be called once, for C, not once per tag. Similarly with current AC_LIBTOOL_SYS_LIB_STRIP. OK to apply to branch-1-5 and forward-port (HEAD has only the STRIP_LIB part missing, I believe)? Cheers, Ralf * libtool.m4 (AC_LIBTOOL_LANG_C_CONFIG) (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_LANG_F77_CONFIG) (AC_LIBTOOL_LANG_GCJ_CONFIG): Only call AC_LIBTOOL_SYS_LIB_STRIP and AC_LIBTOOL_DLOPEN_SELF in the C case, and without the tag argument. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.118 diff -u -r1.314.2.118 libtool.m4 --- libtool.m4 31 Oct 2005 18:54:20 - 1.314.2.118 +++ libtool.m4 31 Oct 2005 21:09:22 - @@ -2650,7 +2650,7 @@ AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) +AC_LIBTOOL_DLOPEN_SELF # Report which librarie types wil actually be built AC_MSG_CHECKING([if libtool supports shared libraries]) @@ -3654,8 +3654,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) AC_LIBTOOL_CONFIG($1) @@ -3920,8 +3918,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP - AC_LIBTOOL_CONFIG($1) @@ -3982,8 +3978,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) AC_LIBTOOL_CONFIG($1)
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Hi Kean,
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:06:10AM CET:
>
> The test for a suitable nm was too restrictive. First, it would only check
> for nm with $ac_tool_prefix. But only the GNU version of nm installs itself
> that way. This was thwarting finding a non-binutils nm on the path.
Erm, are you using --host when configuring? If so, why (are you cross
compiling)? If not, $ac_tool_prefix should be empty. In any case,
while a search for a nm without the prefix is ok (since that's what
AC_CHECK_TOOL does as well), I'm a bit uneasy about the search order: it
should check for prefixed nm everywhere first, and unprefixed
afterwards.
> Second, added /usr/ccs/bin/elf to the list of paths to search, before
> /usr/ccs/bin. On OpenServer, this makes sure we pick up the ELF version,
> as it is a multi-ABI world, and /usr/ccs/bin/nm is a COFF/ELF schizophrenic
> version that accepts slightly different arguments. This wont affect any
> other systems becuase AFAIK only OSR5 has a /usr/ccs/bin/elf, and any
> other system that may conceivably have it is likely to want the ELF version
> of nm anyway.
I assume this change is ok. (Searching the net for the string
/usr/ccs/bin/elf hasn't turned up much :)
> Third, dont do the 'sed 1q' stuff, but grep the output returned. The
> 'sed 1q' was causing false negatives if there was only a single line of
> output. By using grep on the entire output, we will still get the correct
> result, even on HP-UX if it first ejects a warning message about unknown
> options.
I'm pretty sure your change breaks the intended workaround for HPUX.
OTOH, I have absolutely no idea about its relevance today; it dates from
1997/11/28, and I don't have any more information about this available
(and no access to HP-UX).
In any case, I believe you got the logic wrong there: /dev/null being
present in the output is taken as a _positive_ sign, ie. that nm
understands -B, iff present in the first line. What does
nm -B /dev/null
on SCO output, by the way? Maybe we can adjust the old scheme to that?
Furthermore, I really don't like that you changed a shell pattern match
to a slow grep; also, please note that grep regexes are different from
shell patterns in that they aren't anchored, so you don't need all those
`.*'.
I'm wondering whether it's easiest to just create an object file first.
Will be most expensive, but most reliable, too..
Cheers,
Ralf
> 2005-10-24 Kean Johnston <[EMAIL PROTECTED]>
>
> * libtool.m4(AC_PROG_NM): Add /usr/ccs/bin/elf to search path list.
> Look for tool both with and without ac_tool_prefix. Use grep on output
> results and dont delete first line of output in case output is
> only one line long.
>
> Index: libtool.m4
> ===
> RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
> retrieving revision 1.314.2.115
> diff -u -3 -p -r1.314.2.115 libtool.m4
> --- libtool.m49 Oct 2005 06:26:21 - 1.314.2.115
> +++ libtool.m430 Oct 2005 21:22:24 -
> @@ -2375,33 +2386,37 @@ AC_DEFUN([AC_PROG_NM],
>lt_cv_path_NM="$NM"
> else
>lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
> - for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
> + for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
> IFS="$lt_save_ifs"
> test -z "$ac_dir" && ac_dir=.
> -tmp_nm="$ac_dir/${ac_tool_prefix}nm"
> -if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
> +tmp_nm_file="$ac_dir/${ac_tool_prefix}nm"
> +if test -f "$tmp_nm_file" || test -f "$tmp_nm_file$ac_exeext" ; then
> + tmp_nm=$tmp_nm_file
> +else
> + tmp_nm_file="$ac_dir/nm"
> + if test -f "$tmp_nm_file" || test -f "$tmp_nm_file$ac_exeext" ; then
> +tmp_nm=$tmp_nm_file
> + fi
> +fi
> +if test -n "$tmp_nm" ; then
># Check to see if the nm accepts a BSD-compat flag.
> - # Adding the `sed 1q' prevents false positives on HP-UX, which says:
> - # nm: unknown option "B" ignored
># Tru64's nm complains that /dev/null is an invalid object file
> - case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
> - */dev/null* | *'Invalid file or object type'*)
> - lt_cv_path_NM="$tmp_nm -B"
> + tmp_nm_out=`$tmp_nm -B /dev/null 2>&1`
> + echo "$tmp_nm_out" | $EGREP '.*/dev/null.*|.*Invalid file or object
> type.*' > /dev/null 2>&1
> + if test $? -eq 0; then
> +lt_cv_path_NM="$tmp_nm -B"
> break
> -;;
> - *)
> - case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
> - */dev/null*)
> + else
> +tmp_nm_out=`$tmp_nm -p /dev/null 2>&1`
> +echo "$tmp_nm_out" | $EGREP '.*/dev/null.*' > /dev/null 2>&1
> + if test $? -eq 0; then
> lt_cv_path_NM="$tmp_nm -p"
> break
> - ;;
> - *)
> + else
> lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
> continue # so that we can try to find one tha
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 06:43:03PM CET: > >Patch 7 of 10 attached ... > > Here's a re-submission using install_libdir instead of the > 'instrpath' hack I invented. > Rationale: > > I like it when things work on my platform :) Ugh. It's really difficult to judge over this huge patch -- would have been much easier without the SCOABSPATH part. Also, I haven't checked closely yet (other eyes appreciated!), so I'll only give a few suggestions: - the SCOABSPATH stuff should likely be replaced by a generic libtool option to achieve the same thing, or dropped. Failing that, libtool should to things on SCO the way it does on other platforms, ie. hardcode the stuff that's not found by default. (New features are post 2.0, by the way.) - You may and should use `~' as command separator in *_cmds, together with newlines. For example: foo_cmds='ls~echo~cat baz~ if $foo; then bar; fi' - Ideally, C++ support should be tested with CVS HEADs template library tests first.. but that is optional. - the `-belf' setting (sco3.2v5*) vanished completely: | - sco3.2v5*) | -_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf' Oversight? If not: it's the only cruft that uses lt_prog_cc_shlib at all, so the whole bag of that can go as well. - the ChangeLog entry is, umm, a bit terse. But granted, it's not needed until the rest is in good shape. By the way, is there good online documentation for these systems' ld and dynamic loader? Cheers, Ralf > 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> > > * libtool.m4: Complete overhaul of SCO support. >
pointer conversion errors
I'm not sure whether I need to ask for approval for this patch..
Anyway, I'll apply this to branch-1-5 and HEAD unless someone disagrees.
Without it, IBM compilers barf over this in picky mode. I believe it
even be necessary as per C standard.
Sorry for the delay.
Cheers,
Ralf
2005-11-01 Tom Kacvinsky <[EMAIL PROTECTED]> (tiny change)
* libltdl/ltdl.c (lt_dlforeachfile): Cast function to data
pointers.
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.20
diff -u -r1.174.2.20 ltdl.c
--- libltdl/ltdl.c 13 Oct 2005 04:48:50 - 1.174.2.20
+++ libltdl/ltdl.c 31 Oct 2005 18:44:21 -
@@ -3756,31 +3756,31 @@
/* If a specific path was passed, search only the directories
listed in it. */
is_done = foreach_dirinpath (search_path, 0,
- foreachfile_callback, func, data);
+ foreachfile_callback, (void *)func, data);
}
else
{
/* Otherwise search the default paths. */
is_done = foreach_dirinpath (user_search_path, 0,
- foreachfile_callback, func, data);
+ foreachfile_callback, (void *)func, data);
if (!is_done)
{
is_done = foreach_dirinpath (getenv("LTDL_LIBRARY_PATH"), 0,
- foreachfile_callback, func, data);
+ foreachfile_callback, (void *)func,
data);
}
#ifdef LTDL_SHLIBPATH_VAR
if (!is_done)
{
is_done = foreach_dirinpath (getenv(LTDL_SHLIBPATH_VAR), 0,
- foreachfile_callback, func, data);
+ foreachfile_callback, (void *)func,
data);
}
#endif
#ifdef LTDL_SYSSEARCHPATH
if (!is_done)
{
is_done = foreach_dirinpath (getenv(LTDL_SYSSEARCHPATH), 0,
- foreachfile_callback, func, data);
+ foreachfile_callback, (void *)func,
data);
}
#endif
}
inherited_linker_flags repetition
We need to do something about repeated inherited_linker_flags. Happens with CVS HEAD but not branch-1-5, obviously. It's not *quite* as trivial as it looks like, when flags with arguments come into play. Any takers? Cheers, Ralf /bin/sh ../../../../libtool --tag=CC --mode=link gcc -O3 -DNDEBUG -fno-strict-aliasing -pthread -module -avoid-version -export-dynamic -o mca_coll_self.la -rpath /tmp/install/lib/openmpi coll_self_allgather.lo coll_self_allgatherv.lo coll_self_allreduce.lo coll_self_alltoall.lo coll_self_alltoallv.lo coll_self_alltoallw.lo coll_self_barrier.lo coll_self_bcast.lo coll_self_component.lo coll_self_gather.lo coll_self_gatherv.lo coll_self_module.lo coll_self_reduce.lo coll_self_reduce_scatter.lo coll_self_scan.lo coll_self_exscan.lo coll_self_scatter.lo coll_self_scatterv.lo /tmp/build/ompi/libmpi.la /tmp/build/orte/liborte.la /tmp/build/opal/libopal.la -lm -lutil -lnsl libtool: link: rm -f -r .libs/mca_coll_self.la .libs/mca_coll_self.lai .libs/mca_coll_self.so libtool: link: gcc -shared .libs/coll_self_allgather.o .libs/coll_self_allgatherv.o .libs/coll_self_allreduce.o .libs/coll_self_alltoall.o .libs/coll_self_alltoallv.o .libs/coll_self_alltoallw.o .libs/coll_self_barrier.o .libs/coll_self_bcast.o .libs/coll_self_component.o .libs/coll_self_gather.o .libs/coll_self_gatherv.o .libs/coll_self_module.o .libs/coll_self_reduce.o .libs/coll_self_reduce_scatter.o .libs/coll_self_scan.o .libs/coll_self_exscan.o .libs/coll_self_scatter.o .libs/coll_self_scatterv.o -Wl,-rpath -Wl,/tmp/build/ompi/.libs -Wl,-rpath -Wl,/tmp/build/orte/.libs -Wl,-rpath -Wl,/tmp/build/opal/.libs -Wl,-rpath -Wl,/tmp/install/lib /tmp/build/ompi/.libs/libmpi.so -L/tmp/build/orte/.libs -L/tmp/build/opal/.libs /tmp/build/orte/.libs/liborte.so /tmp/build/opal/.libs/libopal.so -ldl -lm -lutil -lnsl -pthread -pthread -pthread -pthread -pthread -pthread -pthread -Wl,-soname -Wl,mca_coll_self.so -o .libs/mca_coll_self.so
