[SCM] GNU Libtool branch, master, updated. v2.2.10-208-gbff43a8
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via bff43a89559b2be74250d990e18b1b64ec073b3a (commit)
from 09142eaeda3b3055653afc302fe871740d65d5c7 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit bff43a89559b2be74250d990e18b1b64ec073b3a
Author: Peter Rosin p...@lysator.liu.se
Date: Wed Sep 22 09:58:47 2010 +0200
tests: reloadable objects do not work on MSVC, SKIP test.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
[cygwin, mingw, pw32, cegcc] cl*, reload_cmds: Indicate that
reloadable objects do not work.
* tests/duplicate_conv.at: Skip last test if reloadable
objects do not work.
* doc/libtool.texi (libtool script contents) reload_cmds:
Document how to indicate that reloadable objects do not work.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
Summary of changes:
ChangeLog | 11 +++
doc/libtool.texi|3 ++-
libltdl/m4/libtool.m4 |5 +
tests/duplicate_conv.at |4
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e011a9e..7ecc325 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-09-22 Peter Rosin p...@lysator.liu.se
+
+ tests: reloadable objects do not work on MSVC, SKIP test.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
+ [cygwin, mingw, pw32, cegcc] cl*, reload_cmds: Indicate that
+ reloadable objects do not work.
+ * tests/duplicate_conv.at: Skip last test if reloadable
+ objects do not work.
+ * doc/libtool.texi (libtool script contents) reload_cmds:
+ Document how to indicate that reloadable objects do not work.
+
2010-09-21 Peter Rosin p...@lysator.liu.se
msvc: eliminate spaces in the library search path.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 0d3ff7f..7688871 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6767,7 +6767,8 @@ replaced by the toolchain format of @code{@@OUTPUT@@}.
Normally disabled
@defvar reload_cmds
@defvarx reload_flag
-Commands to create a reloadable object.
+Commands to create a reloadable object. Set @code{reload_cmds} to
+...@samp{false} on systems that cannot create reloadable objects.
@end defvar
@defvar runpath_var
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a048b1f..d812584 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3081,6 +3081,11 @@ case $reload_flag in
esac
reload_cmds='$LD$reload_flag -o $output$reload_objs'
case $host_os in
+ cygwin* | mingw* | pw32* | cegcc*)
+if test $GCC != yes; then
+ reload_cmds=false
+fi
+;;
darwin*)
if test $GCC = yes; then
reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
diff --git a/tests/duplicate_conv.at b/tests/duplicate_conv.at
index 83d5144..77496d0 100644
--- a/tests/duplicate_conv.at
+++ b/tests/duplicate_conv.at
@@ -25,6 +25,8 @@
AT_SETUP([duplicate convenience archive names])
AT_KEYWORDS([libtool])
+eval `$LIBTOOL --config | sed -n '/^reload_cmds=/,/^$/p'`
+
# We create two convenience archives with the same name, and _also_
# containing an object with the same name. This is necessary to detect
# the failure with both 1.5.22 and HEAD, since the latter does not (did
@@ -75,6 +77,8 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o
main$EXEEXT main.$OBJEXT
LT_AT_EXEC_CHECK([./main],[0],[ignore],[ignore])
$LIBTOOL --mode=clean rm -f libcee.la
+AT_CHECK([test x$reload_cmds = xfalse exit 77], [1])
+
# Test whether this works with reloadable objects as well.
AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT
c.lo a/liba.la b/liba.la],
[0], [ignore], [ignore])
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool annotated tag, v2.4, created. v2.4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, v2.4 has been created at fd9f12048e1fd25f5bd3617135abe7fba2f47705 (tag) tagging e9170e0daf1880db04269434ab0ef8872b9cb4f7 (commit) replaces v2.2.10 tagged by Gary V. Vaughan on Wed Sep 22 23:26:12 2010 +0700 - Log - release 2.4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iEYEABECAAYFAkyaLiUACgkQFRMICSmD1gYV1gCeJysb1saOkm6TGQRX62KDelfZ BcEAn0U71ASLWwXYEBWUFaMuExC79h29 =h6Hq -END PGP SIGNATURE- Charles Wilson (18): [cygwin] Fix segfault in C++ exception handling test [cygwin] Refactor C++ exception handling for Win32 correctness Avoid false failures caused by filesystem interaction [cygwin|mingw] fix dlpreopen with --disable-static Don't always skip XSI tests fix --mode=finish Fix syntax for cygwin-cross [cygwin|mingw|cross-compile]: Path conversion support. Merge remote branch 'origin/master' Minor sysroot fixups. Merge branch 'sysroot' Update path conversion warning messages Path conversion documentation Correct typo: $sharedlib_from_linklib_cmd missing '_cmd' When assigning $linklib value, honor [-all]-static[-libtool-libs] Fix sh.test failure introduced in 72064249 Document libtool variable to_host_file_cmd. Fix order of PATH manipulation in cwrapper and shwrapper Dave Korn (1): Ensure cwrapper magic string is not optimized away. Eric Blake (4): Simplify recent configure quoting portability workaround. maint: ship .xz, not .lzma build: ship autobuild.m4, to reduce bootstrap requirement maint: drop autobuild requirement Gary V. Vaughan (36): Set SCM version number to 2.2.11a. Fix a typu in HACKING. Support shell tracing inside functions even with ksh. Use getopt.m4sh to generate libtoolize option parser. Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer. getopt.m4sh generated libtool option parser, and XSI improvements. Fix portability regressions in today's earlier changeset. Amend a missed opt_mode rename instance in ltmain.m4sh. Use TAB-SPACE in preference to SPACE-TAB. Add missing case branch terminators. Add an XSI replacement for func_split_short_opt, with test cases. Add func_append_quoted and do inline func_append substitutions. Use a real XSI compliant func_split_short_opt substitution. Correct func_split_short_opt comment cut-n-pasto. Add func_append test cases for smart and retarded implementations. Skip `enhanced shell option appending' test when not available. Tidy m4 comment header underline. Fix a cut-n-pasto in 2010-07-07 Charles Wilson patch. Rename _LT_PROG_XSI_REPLACE macro to _LT_PROG_FUNCTION_REPLACE. Fix a spurious trailing space and a botched merge. Make testsuite compatible with Autoconf 2.62 again. Remove double `Generated from foo.m4sh' lines. Remove clcommit.m4sh. Remove announce-gen.m4sh and mailnotify.m4sh. Remove obsolete .cvs ignore files. maint: improve README instructions for fetching latest version. maint: copy the Version Numbering section into README.alpha. maint: consolidate Introductions of README and README.alpha. maint: improve `Reporting Bugs' in README and README.alpha. maint: reformat README `The Test Suites' for consistency. maint: improve README's `Obtaining the Latest Sources'. maint: use sed instead of maintaining 2 README files. maint: edit-readme-alpha shouldn't try to re-edit during dist. tests: ISO C++ forbids declaration of 'v1' with no type. manual: web-manual index.html clashes with @node Index. Release 2.4. Jürgen Reuter (1): Initial support for the NAG Fortran compiler on GNU/Linux. Paolo Bonzini (18): fix bug in postdeps computation handle sysroot flags add --with-sysroot teach libtool -L= and -R= handle sysrooted paths when reading dependencies to la files process postdeps to include sysrooted paths emit sysrooted paths when installing .la files add sysroot test initial version of the NEWS entry fix sysroot tests to pass on Fedora 13 fix sysroot handling for deplibs of preopened libtool libs reorganize parsing of --mode=finish arguments add libtool --mode=finish mode for sysroot improve code for sysroot --mode=finish Factor the sed command used to make a regex from a literal. Merge remote branch 'origin/master' into sysroot Fix sed_make_literal_regex. Merge branch 'master' into sysroot Peter O'Gorman (7): Skip demo-nopic tests if SELinux policy will cause
[SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via f0ba93d85bf975a4fdd0a6fab6b2168c216ce937 (commit) via e9170e0daf1880db04269434ab0ef8872b9cb4f7 (commit) via e3b973b8e10df84cb2ad5d19097cef7590bb8a44 (commit) via ba19397c94378626bc66f44fa75d769490a52ebf (commit) from bff43a89559b2be74250d990e18b1b64ec073b3a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit f0ba93d85bf975a4fdd0a6fab6b2168c216ce937 Author: Gary V. Vaughan g...@gnu.org Date: Wed Sep 22 21:29:36 2010 +0700 Post-release administrivia. * configure.ac, libltdl/configure.ac (AC_INIT): Bump version numbers to 2.4.1a. * NEWS: Add header line for next release. Signed-off-by: Gary V. Vaughan g...@gnu.org commit e9170e0daf1880db04269434ab0ef8872b9cb4f7 Author: Gary V. Vaughan g...@gnu.org Date: Wed Sep 22 21:42:13 2010 +0700 Release 2.4. * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the static libprefix interface, so new version-info is C+1:0:R+1. * configure.ac, libltdl/configure.ac (AC_INIT): Bump version numbers. * NEWS: Update version number. Signed-off-by: Gary V. Vaughan g...@gnu.org commit e3b973b8e10df84cb2ad5d19097cef7590bb8a44 Author: Gary V. Vaughan g...@gnu.org Date: Wed Sep 22 21:41:22 2010 +0700 manual: web-manual index.html clashes with @node Index. * doc/libtool.texi (Index): Renamed to `Combined Index'. Signed-off-by: Gary V. Vaughan g...@gnu.org commit ba19397c94378626bc66f44fa75d769490a52ebf Author: Gary V. Vaughan g...@gnu.org Date: Wed Sep 22 08:48:56 2010 +0700 tests: ISO C++ forbids declaration of 'v1' with no type. * tests/lt_dlexit.at (lt_dlexit unloading libs): Added an explicit int type to declaration of 'v1' to prevent compilation failure with C++. Signed-off-by: Gary V. Vaughan g...@gnu.org --- Summary of changes: ChangeLog| 22 ++ NEWS |8 +++- configure.ac |2 +- doc/libtool.texi |6 +++--- libltdl/Makefile.inc |2 +- libltdl/configure.ac |2 +- tests/lt_dlexit.at |2 +- 7 files changed, 36 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7ecc325..566b74e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,25 @@ +2010-09-22 Gary V. Vaughan g...@gnu.org + + Post-release administrivia. + * configure.ac, libltdl/configure.ac (AC_INIT): Bump version + numbers to 2.4.1a. + * NEWS: Add header line for next release. + + Release 2.4. + * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the + static libprefix interface, so new version-info is C+1:0:R+1. + * configure.ac, libltdl/configure.ac (AC_INIT): Bump version + numbers. + * NEWS: Update version number. + + manual: web-manual index.html clashes with @node Index. + * doc/libtool.texi (Index): Renamed to `Combined Index'. + + tests: ISO C++ forbids declaration of 'v1' with no type. + * tests/lt_dlexit.at (lt_dlexit unloading libs): Added an + explicit int type to declaration of 'v1' to prevent compilation + failure with C++. + 2010-09-22 Peter Rosin p...@lysator.liu.se tests: reloadable objects do not work on MSVC, SKIP test. diff --git a/NEWS b/NEWS index 1d4419b..6e8e0fe 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool -New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team: +New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team: + +* Bug fixes: + + - None yet! + +New in 2.4 2010-09-22: git version 2.2.11a, Libtool team: * New features: diff --git a/configure.ac b/configure.ac index 131cd3b..63ee8bf 100644 --- a/configure.ac +++ b/configure.ac @@ -31,7 +31,7 @@ dnl Oldest automake required for bootstrap is below in AM_INIT_AUTOMAKE. ## ## ## Autoconf initialisation. ## ## ## -AC_INIT([GNU Libtool], [2.2.11a], [bug-libt...@gnu.org]) +AC_INIT([GNU Libtool], [2.4.1a], [bug-libt...@gnu.org]) m4_ifndef([AC_PACKAGE_URL], [AC_SUBST([PACKAGE_URL], [http://www.gnu.org/software/libtool/])]) AC_CONFIG_HEADERS([config.h:config-h.in]) diff --git a/doc/libtool.texi b/doc/libtool.texi index 7688871..56852ca 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -101,7 +101,7 @@ GNU Libtool. * Troubleshooting:: When libtool doesn't work as advertised. * Maintaining:: Information used by the
Re: libtool-2.2.11a on AIX 5.3 current git master 2010-08-25 /status
Hello, On 21.09.2010 19:59, Ralf Wildenhues wrote: Hello Rainer, * Rainer Tammer wrote on Tue, Sep 21, 2010 at 11:15:47AM CEST: after this patch all tests from the old test suite are OK. Great! The new test suite still shows some problems but its getting much better: Yeah. They pass fully with LDFLAGS=-Wl,-brtl. But the failures without runtimelinking are long-standing, not recent regressions. That means we don't have to fix them before the release. Usually I set -Wl,-brtl but in this case I was trying to set as little as possible options. Would it be OK to add this: diff --git a/doc/PLATFORMS b/doc/PLATFORMS index a724144..9d76364 100644 --- a/doc/PLATFORMS +++ b/doc/PLATFORMS @@ -114,6 +114,7 @@ mips-sni-sysv4 gcc 1.3.5ok mipsel-unknown-openbsd2.1 gcc 1.0 ok powerpc-apple-darwin6.4 gcc 1.5 ok (apple dev tools released 12/2002) +powerpc-ibm-aix5.3.0.0 xlc 2.2.12 ok (with LDFLAGS=-Wl,-brtl) powerpc-ibm-aix4.3.1.0 gcc 1.2f ok (egcs-1.1.1) powerpc-ibm-aix4.2.1.0 gcc 1.2f ok and/or diff --git a/README b/README index f88901c..9e8d845 100644 --- a/README +++ b/README @@ -319,6 +319,17 @@ notice and this notice are preserved. This file is offered as-is, without warranty of any kind. +6. Platform specific notes +== + +6.1. AIX + + +On AIX is is recommended to set: + + export LDFLAGS=-Wl,-brtl + + I've pushed the patch now. Gary, I'm done, but Peter Rosin has pending stuff still. OK Thanks again, Ralf Bye Rainer Tammer
Re: libtool-2.2.11a on AIX 5.3 current git master 2010-08-25 /status
* Rainer Tammer wrote on Wed, Sep 22, 2010 at 09:35:38AM CEST:
--- a/README
+++ b/README
@@ -319,6 +319,17 @@ notice and this notice are preserved. This file is
offered as-is,
without warranty of any kind.
+6. Platform specific notes
We already have doc/notes.{texi,txt}.
Cheers,
Ralf
[PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Hi!
This is fixing a testsuite issue for MSVC, and I don't need it
to go in before the release. So, no rush.
The patch was previously discussed here:
http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html
and it is on the pr-msvc-support branch as commit
fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit
happened by mistake and was one of the very unpolished ones).
Ok to push after the 2.4 release? (or before if Gary is ok with that)
(with this patch and the other one making need_lib_prefix.at skip,
there are no more fails for MSVC/MSYS. Boggle!)
Cheers,
Peter
From bff43a89559b2be74250d990e18b1b64ec073b3a Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Wed, 22 Sep 2010 09:58:47 +0200
Subject: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
[cygwin, mingw, pw32, cegcc] cl*, reload_cmds: Indicate that
reloadable objects do not work.
* tests/duplicate_conv.at: Skip last test if reloadable
objects do not work.
* doc/libtool.texi (libtool script contents) reload_cmds:
Document how to indicate that reloadable objects do not work.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog | 11 +++
doc/libtool.texi|3 ++-
libltdl/m4/libtool.m4 |5 +
tests/duplicate_conv.at |4
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e011a9e..7ecc325 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-09-22 Peter Rosin p...@lysator.liu.se
+
+ tests: reloadable objects do not work on MSVC, SKIP test.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
+ [cygwin, mingw, pw32, cegcc] cl*, reload_cmds: Indicate that
+ reloadable objects do not work.
+ * tests/duplicate_conv.at: Skip last test if reloadable
+ objects do not work.
+ * doc/libtool.texi (libtool script contents) reload_cmds:
+ Document how to indicate that reloadable objects do not work.
+
2010-09-21 Peter Rosin p...@lysator.liu.se
msvc: eliminate spaces in the library search path.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 0d3ff7f..7688871 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6767,7 +6767,8 @@ replaced by the toolchain format of @code{@@OUTPUT@@}.
Normally disabled
@defvar reload_cmds
@defvarx reload_flag
-Commands to create a reloadable object.
+Commands to create a reloadable object. Set @code{reload_cmds} to
+...@samp{false} on systems that cannot create reloadable objects.
@end defvar
@defvar runpath_var
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a048b1f..d812584 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3081,6 +3081,11 @@ case $reload_flag in
esac
reload_cmds='$LD$reload_flag -o $output$reload_objs'
case $host_os in
+ cygwin* | mingw* | pw32* | cegcc*)
+if test $GCC != yes; then
+ reload_cmds=false
+fi
+;;
darwin*)
if test $GCC = yes; then
reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
diff --git a/tests/duplicate_conv.at b/tests/duplicate_conv.at
index 83d5144..77496d0 100644
--- a/tests/duplicate_conv.at
+++ b/tests/duplicate_conv.at
@@ -25,6 +25,8 @@
AT_SETUP([duplicate convenience archive names])
AT_KEYWORDS([libtool])
+eval `$LIBTOOL --config | sed -n '/^reload_cmds=/,/^$/p'`
+
# We create two convenience archives with the same name, and _also_
# containing an object with the same name. This is necessary to detect
# the failure with both 1.5.22 and HEAD, since the latter does not (did
@@ -75,6 +77,8 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o
main$EXEEXT main.$OBJEXT
LT_AT_EXEC_CHECK([./main],[0],[ignore],[ignore])
$LIBTOOL --mode=clean rm -f libcee.la
+AT_CHECK([test x$reload_cmds = xfalse exit 77], [1])
+
# Test whether this works with reloadable objects as well.
AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT
c.lo a/liba.la b/liba.la],
[0], [ignore], [ignore])
--
1.7.1
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Hi Peter, On 22 Sep 2010, at 15:02, Peter Rosin wrote: This is fixing a testsuite issue for MSVC, and I don't need it to go in before the release. So, no rush. The patch was previously discussed here: http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html and it is on the pr-msvc-support branch as commit fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit happened by mistake and was one of the very unpolished ones). Ok to push after the 2.4 release? (or before if Gary is ok with that) (with this patch and the other one making need_lib_prefix.at skip, there are no more fails for MSVC/MSYS. Boggle!) Sure, go ahead. And please add a `no test failures with msvc/msys' entry to NEWS while you're there. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw, pw32, cegcc] cl*, reload_cmds: Indicate that reloadable objects do not work. * tests/duplicate_conv.at: Skip last test if reloadable objects do not work. * doc/libtool.texi (libtool script contents) reload_cmds: Document how to indicate that reloadable objects do not work. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Den 2010-09-22 10:11 skrev Gary V. Vaughan: Hi Peter, On 22 Sep 2010, at 15:02, Peter Rosin wrote: This is fixing a testsuite issue for MSVC, and I don't need it to go in before the release. So, no rush. The patch was previously discussed here: http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html and it is on the pr-msvc-support branch as commit fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit happened by mistake and was one of the very unpolished ones). Ok to push after the 2.4 release? (or before if Gary is ok with that) (with this patch and the other one making need_lib_prefix.at skip, there are no more fails for MSVC/MSYS. Boggle!) Sure, go ahead. And please add a `no test failures with msvc/msys' entry to NEWS while you're there. I assume you mean that both patches are OK to push then? Cheers, Peter
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Den 2010-09-22 10:24 skrev Gary V. Vaughan: Hi Peter, On 22 Sep 2010, at 15:15, Peter Rosin wrote: Den 2010-09-22 10:11 skrev Gary V. Vaughan: Hi Peter, On 22 Sep 2010, at 15:02, Peter Rosin wrote: This is fixing a testsuite issue for MSVC, and I don't need it to go in before the release. So, no rush. The patch was previously discussed here: http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html and it is on the pr-msvc-support branch as commit fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit happened by mistake and was one of the very unpolished ones). Ok to push after the 2.4 release? (or before if Gary is ok with that) (with this patch and the other one making need_lib_prefix.at skip, there are no more fails for MSVC/MSYS. Boggle!) Sure, go ahead. And please add a `no test failures with msvc/msys' entry to NEWS while you're there. I assume you mean that both patches are OK to push then? Both patches? I saw only the one attached to the mail I replied to. That one is fine to push, yes. What's the other one? The one I mentioned in the same sentence where I said no more fails, i.e the other one making need_lib_prefix.at skip. See this thread: http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00201.html Hmm, but no more fails is a truth with modification. The *new* testsuite has no unexpected fails. There are still a bunch of needed __declspec(dllimport) in the old testsuite, and perhaps there are some other fails as well. Not sure actually, I'm not normally running it. Given that, I'll hold back on any bragging in NEWS... Cheers, Peter
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Den 2010-09-22 10:24 skrev Gary V. Vaughan: On 22 Sep 2010, at 15:15, Peter Rosin wrote: Den 2010-09-22 10:11 skrev Gary V. Vaughan: Sure, go ahead. And please add a `no test failures with msvc/msys' entry to NEWS while you're there. I assume you mean that both patches are OK to push then? Both patches? I saw only the one attached to the mail I replied to. That one is fine to push, yes. What's the other one? I have now pushed the patch that you did see. Thanks for the review! Still waiting on the other one, but as I have previously stated this is only a testsuite issue so it is not really that important. Cheers, Peter
Re: libtool-2.2.11a on AIX 5.3 current git master 2010-08-25 /status
Hello,
On 22.09.2010 09:38, Ralf Wildenhues wrote:
* Rainer Tammer wrote on Wed, Sep 22, 2010 at 09:35:38AM CEST:
--- a/README
+++ b/README
@@ -319,6 +319,17 @@ notice and this notice are preserved. This file is
offered as-is,
without warranty of any kind.
+6. Platform specific notes
We already have doc/notes.{texi,txt}.
Sorry,
I missed that :-((
Cheers,
Ralf
Bye
Rainer
[PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
The start of my post-release patch queue... okay to push? * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog |8 Makefile.am |4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 566b74e..77dbb59 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2010-09-01 Gary V. Vaughan g...@gnu.org + + maint: help2man targets should rely on the binaries they call. + * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on + the intermediate files, since they might have changed without + giving make the opportunity to update the actual binaries that + help2man calls in time. + 2010-09-22 Gary V. Vaughan g...@gnu.org Post-release administrivia. diff --git a/Makefile.am b/Makefile.am index 6e29a29..0123180 100644 --- a/Makefile.am +++ b/Makefile.am @@ -326,9 +326,9 @@ MAINTAINERCLEANFILES+= $(dist_man1_MANS) update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ -$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh +$(srcdir)/doc/libtool.1: libtool $(update_mans) --help-option=--help-all libtool -$(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in +$(srcdir)/doc/libtoolize.1: libtoolize $(update_mans) libtoolize -- 1.7.3
[PATCH 2/4] maint: rearrange Makefile.am in preparation for a follow-up patch.
I've posted this one before, but this time it's split into two separate patches. This one to do the rearranging without any changes, and the next to perform the functional edits. Okay to push? * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog | 10 Makefile.am | 142 +- 2 files changed, 81 insertions(+), 71 deletions(-) diff --git a/ChangeLog b/ChangeLog index 77dbb59..14866a9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2010-08-31 Gary V. Vaughan g...@gnu.org + + maint: rearrange Makefile.am in preparation for a follow-up patch. + * Makefile.am (Libtool scripts.): Move this section below the + `Bootstrap.' section... + (libtoolize.in): ...except this one which is generated at + bootstrap time, and was added into the `Bootstrap.' section. + (Libltdl.): Move this section below the `Libtool scripts.' + section. + 2010-09-01 Gary V. Vaughan g...@gnu.org maint: help2man targets should rely on the binaries they call. diff --git a/Makefile.am b/Makefile.am index 0123180..1f3c584 100644 --- a/Makefile.am +++ b/Makefile.am @@ -60,63 +60,21 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \ rebuild = rebuild=:; $(timestamp); correctver=$$1 -## ## -## Libtool scripts. ## -## ## - -# The libtool distributor and the standalone libtool script. -bin_SCRIPTS = libtoolize libtool - -libtoolize: $(srcdir)/libtoolize.in $(top_builddir)/config.status - rm -f libtoolize.tmp libtoolize - $(timestamp); \ - $(edit) -e s,@TIMESTAMP\@,$$TIMESTAMP,g \ - -e 's,@aclocal_DATA\@,$(aclocalfiles),g' \ - -e s,@pkgltdl_files\@,$(ltdldatafiles),g \ - -e s,@pkgconfig_files\@,$(auxfiles),g \ - $(srcdir)/libtoolize.in libtoolize.tmp - chmod a+x libtoolize.tmp - chmod a-w libtoolize.tmp - mv -f libtoolize.tmp libtoolize - -# Use `$(srcdir)' for the benefit of non-GNU makes: this is -# how libtoolize.in appears in our dependencies. -EXTRA_DIST += libtoolize.m4sh -$(srcdir)/libtoolize.in: $(sh_files) libtoolize.m4sh Makefile.am - cd $(srcdir); \ - rm -f libtoolize.in; \ - $(M4SH) -B $(auxdir) libtoolize.m4sh libtoolize.in - -# We used to do this with a 'stamp-vcl' file, but non-gmake builds -# would rerun configure on every invocation, so now we manually -# check the version numbers from the build rule when necessary. -libtool: $(top_builddir)/config.status $(srcdir)/$(auxdir)/ltmain.sh ChangeLog - @target=libtool; $(rebuild); \ - if test -f $$target; then \ - set dummy `./$$target --version | sed 1q`; actualver=$$5; \ - test $$actualver = $$correctver rebuild=false; \ - fi; \ - for prereq in $?; do \ - case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ - done; \ - if $$rebuild; then \ - echo $(SHELL) ./config.status $$target; \ - cd $(top_builddir) $(SHELL) ./config.status $$target; \ - fi - -.PHONY: configure-subdirs -configure-subdirs distdir: $(DIST_MAKEFILE_LIST) -...@dist_makefile_list@: - dir=`echo $@ | sed 's,^[^/]*$$,.,;s,/[^/]*$$,,'`; \ - test -d $$dir || mkdir $$dir || exit 1; \ - abs_srcdir=`$(lt__cd) $(srcdir) pwd`; \ - (cd $$dir $$abs_srcdir/$$dir/configure --with-dist) || exit 1 - - # -- # # Bootstrap. # # -- # +sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh +EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ + $(auxdir)/mkstamp $(sh_files) \ + ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \ + ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \ + ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \ + ChangeLog.2005 ChangeLog.2006 ChangeLog.2007 \ + ChangeLog.2008 ChangeLog.2009 +CLEANFILES += libtool libtoolize libtoolize.tmp \ + $(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp + edit = sed \ -e 's,@EGREP\@,$(EGREP),g' \ -e 's,@FGREP\@,$(FGREP),g' \ @@ -138,17 +96,6 @@ edit = sed \ -e 's,@host_triplet\@,$(host_triplet),g' \ -e 's,@prefix\@,$(prefix),g' -sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh -EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ - $(auxdir)/mkstamp $(sh_files) \ - ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \ - ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \ - ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \ -
[PATCH 3/4] maint: don't leak developer GREP, SED etc into distribution file.
This is the second part of the patch I've split since the last time I posted. I added Joerg as reporter, and he is already named in THANKS. Okay to push? * Makefile.am: Having rearranged the file, now apply the actual changes to follow-up. (LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the front of the search path. (rebuild): Set the shell variable `revision' rather than `correctver' for clarity. (edit): Split into two parts... (bootstrap_edit): ...substitutions that should happen at bootstrap time... (configure_edit): ...and substitutions that should not happen until configure time. * libtoolize.m4sh (package_revision): For consistency, and ease of extraction when deciding whether libtoolize needs to be regenerated. * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh) (libtoolize.in): Much simplified - only rebuild if the recalculated timestamp is newer than the timestamp recorded in the target already; regenerate in one step without changing directories, using `$(bootstrap_edit)'. (libtoolize, libtool): Hugely simplified - since we already depend on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively, no need to recheck version numbers; also they have the `$(bootstrap_edit)' substitutions made already, so we can just go ahead and process with `$(configure_edit)' whenever the dependencies go out of date. * Makefile.maint (commit, libltdl/config/mailnotify, bootstrap): Likewise. * HACKING (Release Procedure): Remove the note to workaround the bug fixed by this changeset. * NEWS (Bug fixes): Mention that this bug is now fixed. Reported by Joerg Sonnenberger. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog | 33 ++ HACKING |9 --- Makefile.am | 178 +- NEWS|3 +- libtoolize.m4sh |1 + 5 files changed, 118 insertions(+), 106 deletions(-) diff --git a/ChangeLog b/ChangeLog index 14866a9..fe75e0f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,38 @@ 2010-08-31 Gary V. Vaughan g...@gnu.org + maint: don't leak developer GREP, SED etc into distribution file. + * Makefile.am: Having rearranged the file, now apply the actual + changes to follow-up. + (LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the + front of the search path. + (rebuild): Set the shell variable `revision' rather than + `correctver' for clarity. + (edit): Split into two parts... + (bootstrap_edit): ...substitutions that should happen at bootstrap + time... + (configure_edit): ...and substitutions that should not happen until + configure time. + * libtoolize.m4sh (package_revision): For consistency, and ease of + extraction when deciding whether libtoolize needs to be + regenerated. + * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh) + (libtoolize.in): Much simplified - only rebuild if the + recalculated timestamp is newer than the timestamp recorded in the + target already; regenerate in one step without changing + directories, using `$(bootstrap_edit)'. + (libtoolize, libtool): Hugely simplified - since we already depend + on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively, + no need to recheck version numbers; also they have the + `$(bootstrap_edit)' substitutions made already, so we can just + go ahead and process with `$(configure_edit)' whenever the + dependencies go out of date. + * Makefile.maint (commit, libltdl/config/mailnotify, bootstrap): + Likewise. + * HACKING (Release Procedure): Remove the note to workaround the + bug fixed by this changeset. + * NEWS (Bug fixes): Mention that this bug is now fixed. + Reported by Joerg Sonnenberger. + maint: rearrange Makefile.am in preparation for a follow-up patch. * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... diff --git a/HACKING b/HACKING index 977be10..b17de29 100644 --- a/HACKING +++ b/HACKING @@ -619,15 +619,6 @@ or obtained by writing to the Free Software Foundation, Inc., * Update NEWS, ChangeLog. -* Until the bug that leaks developer tool paths into the release tarballs - from ./bootstrap is fixed, make sure the right tools are first in your - PATH and then: - export EGREP=egrep - export FGREP=fgrep - export GREP=grep - export MAKE=make - export SED=sed - * Run ./bootstrap. * Run ./configure (or create a build directory first and run configure diff --git a/Makefile.am b/Makefile.am index 1f3c584..48cd3a7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -43,6 +43,8 @@ noinst_LTLIBRARIES= lib_LTLIBRARIES= EXTRA_LTLIBRARIES = +LT_M4SH= $(M4SH) -B $(srcdir)/$(auxdir) + auxdir = libltdl/config m4dir = libltdl/m4 @@
Re: [SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d
Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:27:27PM CEST: * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the static libprefix interface, so new version-info is C+1:0:R+1. libprefix is a *static* local undocumented variable, not public API. There was no reason to bump the API version for this. :-( Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 09/22/2010 11:35 AM, Ralf Wildenhues wrote: Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: The start of my post-release patch queue... okay to push? * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
Hi Eric, * Eric Blake wrote on Wed, Sep 22, 2010 at 07:37:58PM CEST: On 09/22/2010 11:35 AM, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? There are differences in semantics between GNU and some non-GNU make implementations in the way that some of the latter may always consider some prerequisite updated if they invoked the rule for updating the prerequisite. I'm hoping these makes die out, but we aren't quite there yet. Cheers, Ralf
Fix regression in command-line length computation.
Oh brother, I just found another regression. :-(
func_fallback_echo isn't even defined inside configure unless we haven't
found a better $ECHO. We should be trying to forkexec an external
utility with the test string, so that we are actually testing the right
limit.
I'm pushing the fix below, which I've checked by using set -x
generously and disabling the getconf mechanism, on GNU/Linux.
One should note that recent Linux kernels do not actually have a limit
on the maximum total command-line length any more, but they do have a
limit on the maximum length of a single command-line argument. Now,
ignoring the presence of getconf for a moment, I figured we should maybe
be able to exploit this, but there's a glitch: our testing of
expr X$cmd : .*
inside both libtool.m4 and ltmain.sh passes the whole command-line as
one argument to expr. It /might/ be possible to get around this in
practice by using XSI shell internals if possible (and eventually we
should be trying something to that extent anyway for efficiency
reasons), but the whole area is sufficiently subtle that I would like
to postpone any further non-regression-fixing action to well later.
Thanks,
Ralf
Fix regression in command-line length computation.
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Use `env echo' rather
than possibly-undefined func_fallback_echo, to ensure we fork
and exec for this test.
* NEWS: Update.
Regression introduced in v2.2.6-39-g9c3d4d8.
diff --git a/NEWS b/NEWS
index 6e8e0fe..90e33f7 100644
--- a/NEWS
+++ b/NEWS
@@ -4,7 +4,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
* Bug fixes:
- - None yet!
+ - The generic approximation of the command line length limit (when getconf is
+not available) works again. Regression introduced in v2.2.6-39-g9c3d4d8.
New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d812584..6aebb63 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1639,7 +1639,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
# 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
# we can't tell.
- while { test X`func_fallback_echo $teststring$teststring
2/dev/null` \
+ while { test X`env echo $teststring$teststring 2/dev/null` \
= X$teststring$teststring; } /dev/null 21
test $i != 17 # 1/2 MB should be enough
do
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: On 09/22/2010 12:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? diff --git i/Makefile.am w/Makefile.am index 6e29a29..f74708c 100644 --- i/Makefile.am +++ w/Makefile.am @@ -327,8 +327,10 @@ update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize Likewise here. Cheers, Ralf
Re: [PATCH 2/4] maint: rearrange Makefile.am in preparation for a follow-up patch.
Hi Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:49PM CEST: * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. This move-only patch is fine with me. I am kind of wondering whether we should wait a little bit for other deal-breaking regressions necessitating an updated release, but then again, in that case we can (and should!) start a maint branch off of v2.4-2-g67bbe04 and do a 2.4b from there. Thanks, Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 09/22/2010 12:22 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. Any ideas on how to avoid such a race? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Eric Blake wrote on Wed, Sep 22, 2010 at 08:30:08PM CEST: On 09/22/2010 12:22 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. Any ideas on how to avoid such a race? 1) .NOTPARALLEL: Is not a good idea because it will make 'make -j3 check' slow again. :-/ And if you require non-parallel builds, then you can again rely on the fact that Posix make will update prerequisites in the order listed, so that all you need to ensure is that all-am depends on 'libtool' earlier than it depends on '$(srcdir)/doc/libtool.1'. 2) Use a subdir Makefile.am in doc, as SUBDIRS is a serializer. Update the manpage in doc/Makefile.am, and have 'SUBDIRS = . doc' in toplevel so that it is updated first. 3) GNU make could use order-only prerequisites, but that is far too unportable, as many practical GNU make installations are too old still. 4) BUILT_SOURCES = libtool libtoolize Wait ... we are using (4) already. Why does it not work? IOW, I don't see the failure mode which this patch is supposed to fix. Please show a verbose make log exhibiting the failure. I'm guessing there is a different actual reason for the failure. Thanks, ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 23 Sep 2010, at 00:35, Ralf Wildenhues wrote: Hello Gary, Hallo Ralf, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: The start of my post-release patch queue... okay to push? * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Yuck. Another reason to always start afresh after making changes rather than relying on make to DTRT :( In my case, ltmain.sh was corrupted, but even though I fixed it, rerunning make ended up leaving the empty manpages generated by a libtool script that had no --version output, and *then* it proceeded to rebuild ltmain.sh. Is there no way to make sure help2man doesn't run until the programs it wants to call have been rebuilt, rather than building (and potentially distributing) manpages documenting options from the previous script? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:29:44PM CEST: On 23 Sep 2010, at 00:35, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Yuck. Another reason to always start afresh after making changes rather than relying on make to DTRT :( In my case, ltmain.sh was corrupted, but even though I fixed it, rerunning make ended up leaving the empty manpages generated by a libtool script that had no --version output, and *then* it proceeded to rebuild ltmain.sh. I can try to debug it, if you can show me how to reliably reproduce the failure. Is there no way to make sure help2man doesn't run until the programs it wants to call have been rebuilt, rather than building (and potentially distributing) manpages documenting options from the previous script? I outlined four separate possible approaches for this in another mail in this thread already. Cheers, Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:36:01PM CEST: On 23 Sep 2010, at 01:22, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: On 09/22/2010 12:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize Likewise here. How about a putting the shell code for libtoolize.in - libtoolize transformation and writing: $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in $(generate_libtoolize) $(update_mans) libtoolize That will not help, because 'make' may still run it in parallel with the commands from the 'libtoolize' rule. Cheers, Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 23 Sep 2010, at 01:22, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: On 09/22/2010 12:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? diff --git i/Makefile.am w/Makefile.am index 6e29a29..f74708c 100644 --- i/Makefile.am +++ w/Makefile.am @@ -327,8 +327,10 @@ update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh +$(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in +$(MAKE) libtoolize $(update_mans) libtoolize Likewise here. How about a putting the shell code for libtoolize.in - libtoolize transformation and writing: $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in $(generate_libtoolize) $(update_mans) libtoolize Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 4/4] maint: simplify and improve safety of bootstrap process.
Hi Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:51PM CEST: I also posted this one before... this time rebased against post-2.4 release HEAD. Okay to push? Assuming strongly that this patch depends upon the semantics of 3/4 applied, I will review this patch after 3/4 is fixed. Thanks, Ralf * Makefile.am (bootstrap_files): List files that need to be generated at bootstrap time before `./configure make' can work. It turns out that this is considerably fewer files than we had thought necessary previously. (bootstrap-deps-prep): Ensure minimum set of required substitution variables are non-empty. (bootstrap-deps): Depend on `bootstrap' files. * bootstrap (Generate bootstrap dependencies): Now that `Makefile.am' is entirely responsible for rebuilding files at bootstrap time, we need only specify the new `bootstrap-deps' target, and supply values for the substitutions checked by `bootstrap-deps-prep'.
Re: [PATCH 3/4] maint: don't leak developer GREP, SED etc into distribution file.
Hi Gary,
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:50PM CEST:
This is the second part of the patch I've split since the last
time I posted. I added Joerg as reporter, and he is already
named in THANKS.
Okay to push?
With this patch applied, the generated libtool script still contains
the following lines:
: ${EGREP=@EGREP@}
: ${FGREP=@FGREP@}
: ${GREP=@GREP@}
: ${LN_S=@LN_S@}
[...]
: ${SED=@SED@}
Now, the lines are all ineffective, because the tag variables (which
will be expanded before these lines) will set all of these variables.
Kind of ugly, but alright if you prefer to clean that up later.
Secondly, with this patch, and with the nits I wrote inline in the patch
below fixed, still freebsd-make (which is from the freebsd-buildutils
7.0-2 Debian package, and is a somewhat older FreeBSD make built for
GNU/Linux) keeps on rerunning aclocal each time I invoke make. This
means something is not quite right in the rebuild rules, and it will
probably show up with at least one of the major BSD systems' make
implementations. Please fix and repost, I will finish review then.
In case of doubt it might be easier to not try to change the actual
dependency graph at all, but merely the rules, which should be enough
to fix the problem you are targeting.
Thanks,
Ralf
* Makefile.am: Having rearranged the file, now apply the actual
changes to follow-up.
(LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the
front of the search path.
(rebuild): Set the shell variable `revision' rather than
`correctver' for clarity.
(edit): Split into two parts...
(bootstrap_edit): ...substitutions that should happen at bootstrap
time...
(configure_edit): ...and substitutions that should not happen until
configure time.
* libtoolize.m4sh (package_revision): For consistency, and ease of
extraction when deciding whether libtoolize needs to be
regenerated.
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh)
(libtoolize.in): Much simplified - only rebuild if the
recalculated timestamp is newer than the timestamp recorded in the
target already; regenerate in one step without changing
directories, using `$(bootstrap_edit)'.
(libtoolize, libtool): Hugely simplified - since we already depend
on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively,
no need to recheck version numbers; also they have the
`$(bootstrap_edit)' substitutions made already, so we can just
go ahead and process with `$(configure_edit)' whenever the
dependencies go out of date.
* Makefile.maint (commit, libltdl/config/mailnotify, bootstrap):
Likewise.
* HACKING (Release Procedure): Remove the note to workaround the
bug fixed by this changeset.
* NEWS (Bug fixes): Mention that this bug is now fixed.
Reported by Joerg Sonnenberger.
--- a/Makefile.am
+++ b/Makefile.am
@@ -43,6 +43,8 @@ noinst_LTLIBRARIES =
lib_LTLIBRARIES =
EXTRA_LTLIBRARIES=
+LT_M4SH = $(M4SH) -B $(srcdir)/$(auxdir)
+
auxdir = libltdl/config
m4dir= libltdl/m4
@@ -57,7 +59,7 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \
*) TIMESTAMP= ;; \
esac
-rebuild = rebuild=:; $(timestamp); correctver=$$1
+rebuild = rebuild=:; $(timestamp); revision=$$1
# -- #
@@ -75,26 +77,23 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in
$(auxdir)/ltmain.m4sh \
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-edit = sed \
- -e 's,@EGREP\@,$(EGREP),g' \
- -e 's,@FGREP\@,$(FGREP),g' \
- -e 's,@GREP\@,$(GREP),g' \
- -e 's,@LN_S\@,$(LN_S),g' \
- -e 's,@MACRO_VERSION\@,$(VERSION),g' \
- -e 's,@PACKAGE\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
- -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
- -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
- -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
- -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
- -e 's,@SED\@,$(SED),g' \
- -e 's,@VERSION\@,$(VERSION),g' \
- -e 's,@aclocaldir\@,$(aclocaldir),g' \
- -e 's,@datadir\@,$(datadir),g' \
- -e 's,@pkgdatadir\@,$(pkgdatadir),g' \
- -e 's,@host_triplet\@,$(host_triplet),g' \
- -e 's,@prefix\@,$(prefix),g'
+## These are the replacements that need to be made at bootstrap time,
+## because they must be static in distributed files, and not accidentally
+## changed by configure running on the build machine.
+bootstrap_edit = \
+ -e 's,@MACRO_VERSION\@,$(VERSION),g' \
How come the *_edit variables lost their 'sed' command? Is that because
a later patch will use more than one of them inside one sed script? In
that case, OK with me.
+ -e s,@MACRO_REVISION\@,$$revision,g \
+ -e s,@MACRO_SERIAL\@,$$serial,g \
+ -e
[PATCH] relax -rpath argument test for Snow Leopard
Hello, I had to patch libtool in order to get shared libraries to build with the Snow Leopard '@rpath/' syntax which stands in for the place where the lib gets installed. I thought that this might be useful for more than just myself. Cheers, Leo From a7f66c6ae219f335d79464350d76245a707e56f9 Mon Sep 17 00:00:00 2001 From: Leo Davis lda...@fonix.com Date: Wed, 22 Sep 2010 19:29:11 -0600 Subject: [PATCH] relax -rpath argument test for Snow Leopard * libltdl/config/ltmain.m4sh: Relax the absolute path rules requirement for -rpath a little to allow '@rpath/' to begin the string for Darwin (Snow Leopard) load paths. --- libltdl/config/ltmain.m4sh |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 0418007..3b21851 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -4607,9 +4607,9 @@ func_mode_link () continue ;; rpath | xrpath) - # We need an absolute path. + # We need an absolute path or a runpath. case $arg in - [\\/]* | [A-Za-z]:[\\/]*) ;; + [\\/]* | [A-Za-z]:[\\/]* | @rpath[\\/]*) ;; *) func_fatal_error only absolute run-paths are allowed ;; -- 1.7.2.3
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 23 Sep 2010, at 03:40, Ralf Wildenhues wrote: Hello Gary, Hallo Ralf, Thanks for the swift reviews again. * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:29:44PM CEST: On 23 Sep 2010, at 00:35, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Yuck. Another reason to always start afresh after making changes rather than relying on make to DTRT :( In my case, ltmain.sh was corrupted, but even though I fixed it, rerunning make ended up leaving the empty manpages generated by a libtool script that had no --version output, and *then* it proceeded to rebuild ltmain.sh. I can try to debug it, if you can show me how to reliably reproduce the failure. Thanks. Rather than me chasing my tail trying to tickle that bug again, let's skip this particular patch for now. I pushed it to the front of my queue because it was straight forward and I didn't think it relied on any of my other patches... but quite possibly, the fault is introduced later in one of the Makefile.am changes further down my queue, in which case we'll trip over the bug again soon enough, and can work out a proper fix for it at that time. Is there no way to make sure help2man doesn't run until the programs it wants to call have been rebuilt, rather than building (and potentially distributing) manpages documenting options from the previous script? I outlined four separate possible approaches for this in another mail in this thread already. Except that you ruled out two of them, one involves giving up the advantages of non-recursive make, and the last is already in use! :-p Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] relax -rpath argument test for Snow Leopard
On 09/22/2010 09:00 PM, Leo Davis wrote: Hello, I had to patch libtool in order to get shared libraries to build with the Snow Leopard '@rpath/' syntax which stands in for the place where the lib gets installed. I thought that this might be useful for more than just myself. Well, there is no method to encode @executable_path or @loader_path in the library install_name either. I always figured that people would just build as normal and then postprocess using install_name_tool(1) if they needed to. Why should libtool treat the Mac OS X @rpath differently to the other two special paths? Peter
Re: [PATCH] relax -rpath argument test for Snow Leopard
Hello, * Peter O'Gorman wrote on Thu, Sep 23, 2010 at 07:43:44AM CEST: On 09/22/2010 09:00 PM, Leo Davis wrote: I had to patch libtool in order to get shared libraries to build with the Snow Leopard '@rpath/' syntax which stands in for the place where the lib gets installed. I thought that this might be useful for more than just myself. Well, there is no method to encode @executable_path or @loader_path in the library install_name either. I always figured that people would just build as normal and then postprocess using install_name_tool(1) if they needed to. Why should libtool treat the Mac OS X @rpath differently to the other two special paths? More generally, $ORIGIN support (which is what a number of other linkers call it, IIUC) should be added completely if it's added, including a portable 'libtool' notation, testsuite coverage and fixing of fall-out, and correct treatment of the non-absolute paths throughout ltmain. I don't know how much work the latter would be, but guessing from the sysroot branch, there is work to do there. The most important question to this end is how to degrade gracefully on systems without such a feature. Cheers, Ralf
bogus warning 'seems to be moved'
Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all $ libtool --version libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a on cygwin-1.7.x It is really annoying and filling one third of my building logs with a large project like octave Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
Hello all,
I don't know if my problem suites this description.
On 31/03/2010 6:52 AM, Ralf Wildenhues wrote:
Hello gcc and libtool lists,
Summary: both Autoconf-generated configure tests as well as some Libtool
construct invoke undefined behavior. Question is how to deal with it,
and whether GCC, as QoI, may want to define behavior in these cases.
Currently installed libtool on this system is,
ltmain.sh (GNU libtool) 2.2.6b
I recently tested the LTO feature of GCC (targeting windows) and I found
it was unable to link due to the presence of duplicating lines of *crt*
without compiling with -flto there were not such issues.
It seems that libtool is emitting dllcrt2, crtbegin, crtend all over
again after the first crtend. In the following line.
g++ lib64/dllcrt2.o lib64/crtbegin.o ... _alot_of_other_link_arguments_
... lib64/crtend.o lib64/dllcrt2.o lib64/crtbegin.o lib64/crtend.o
These last three duplicating .o arguments are causing errors.
lib64/dllcrt2.o:crtdll.c:(.text+0x50): multiple definition of `_CRT_INIT'
lib64/dllcrt2.o:crtdll.c:(.text+0x50): first defined here
Is this a know issue?
1) Autoconf-generated configure tests often fake the prototype of some
function; e.g., AC_CHECK_FUNC([func]) uses
char func();
and tries to link that. Using this is undefined according to C99, if
func has a different actual prototype, and when all system libraries are
LTO'ed, gcc -flto may even detect this kind of inconsistency and could
act accordingly (nasal demons and such).
2) libtool has a feature that makes it extract symbol lists from
objects and turn them into fake declarations and function/object
pointers: fake static preloaded modules.
It currently works by running nm or a similar tool over the object, then
converting the output with a couple of sed script or so
(global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
synthesized extra source file that then contains code like this:
extern int func();
extern char variable;
typedef struct {
const char *name;
void *address;
} lt_dlsymlist;
extern const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[];
const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{func, (void *)func},
{variable, (void *)variable},
{0, (void *) 0}
};
This is invoking undefined behavior in a couple of respects:
a) Pointers to functions are stored in pointer-to-void variables.
This could be fixed with an incompatible API change to using a union of
object and function pointer, I guess.
b) The symbols 'func' and 'variable' likely have the wrong prototypes,
i.e., elsewhere, they might be declared as
void func(int, double);
double variable[42];
instead. I haven't come across any actual issues with this yet, except
now LTO may rightfully complain about it.
Question is, what can we do about this? We could ensure to never pass
-flto or -fwhopr to the compilation of the libtool symfile object, and
remove it from some or all link tests done in configure. That's ugly.
Would that even be sufficient though? Conversely, would GCC developers
be willing to agree that, when GCC detects such inconsistencies, it
wouldn't take adverse advantage of it (e.g., by turning off LTO in this
case, or similar)?
Other possibilities for Autoconf would be to work toward a new set of
checking macros (or extensions of current one) where the configure.ac
author passes a full prototype for each function to check (Autoconf
could keep a list of known prototypes for often-checked functions).
I'm not sure how to fix the libtool symfile in a C99-conforming way.
Thanks for reading this far.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
