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
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 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
[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 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 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
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 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 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.
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.
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.
* 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 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 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.
* 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
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 fork&exec 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 2>&1 &&
test $i != 17 # 1/2 MB should be enough
do
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
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 $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize -- 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
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.
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. Cheers, Ralf > --- 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
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
[PATCH 4/4] maint: simplify and improve safety of bootstrap process.
I also posted this one before... this time rebased against post-2.4 release HEAD. Okay to push? * 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'. Signed-off-by: Gary V. Vaughan --- ChangeLog | 16 Makefile.am | 41 + bootstrap | 17 - 3 files changed, 61 insertions(+), 13 deletions(-) diff --git a/ChangeLog b/ChangeLog index fe75e0f..309f8b6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,19 @@ +2010-08-30 Gary V. Vaughan + + maint: simplify and improve safety of bootstrap process. + * 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'. + 2010-08-31 Gary V. Vaughan maint: don't leak developer GREP, SED etc into distribution file. diff --git a/Makefile.am b/Makefile.am index 48cd3a7..0a1b17d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -198,6 +198,47 @@ $(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc -e '1s,^\(.. Makefile.\)inc.*,\1am -- Process this file with automake to produce Makefile.in,' > $$out; chmod a-w $(srcdir)/libltdl/Makefile.am +## Document the make macros that are needed to build bootstrap-deps +## dependencies when called from `bootstrap' (developer's machine), +## where the Makefile.am is fed to make in its raw format before +## `configure' has found the correct values (on the build machine). +bootstrap_files = \ +$(auxdir)/ltmain.sh \ +$(m4dir)/ltversion.m4 \ +libltdl/Makefile.am + +.PHONY: bootstrap-deps bootstrap-deps-prep +bootstrap-deps: bootstrap-deps-prep $(bootstrap_files) +bootstrap-deps-prep: +## The following variables are substituted by `bootstrap-dep-preps' + @exit_cmd=:; \ + test -z "$(srcdir)" \ + && echo "ERROR: don't call $(MAKE) with srcdir unset." \ + && exit_cmd=exit; \ + test -z "$(M4SH)" \ + && echo "ERROR: don't call $(MAKE) with M4SH unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_BUGREPORT)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_BUGREPORT unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_NAME)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_NAME unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_URL)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_URL unset." \ + && exit_cmd=exit; \ + test -z "$(SED)" \ + && echo "ERROR: don't call $(MAKE) with SED unset." \ + && exit_cmd=exit; \ + test -z "$(VERSION)" \ + && echo "ERROR: don't call $(MAKE) with VERSION unset." \ + && exit_cmd=exit; \ + $$exit_cmd 1 + rm -f $(bootstrap_files) + ## Unfortunately, all this bogeyness means that we have to manually ## keep the generated files in libltdl up to date. diff --git a/bootstrap b/bootstrap index 78b4d30..e66b151 100755 --- a/bootstrap +++ b/bootstrap @@ -126,19 +126,10 @@ $SED '/^if /,/^endif$/d;/^else$/,/^endif$/d;/^include /d' $makes > Makefile # Building distributed files from configure is bad for automake, so we # generate them here, and have Makefile rules to keep them up to date. -# We don't have all the substitution values to build ltmain.sh from this -# script yet, but we need config/ltmain.sh for the libtool commands in -# configure, and ltversion.m4 to generate configure in the first place: -rm -f $auxdir/ltmain.sh $m4dir/ltversion.m4 - -$MAKE ./$auxdir/ltmain.sh ./$m4dir/ltversion.m4 \ -./libtoolize.in ./tests/defs.in ./tests/package.m4 \ -./tests/testsuite ./libltdl/Makefile.am ./doc/notes.txt \ -srcdir=. top
[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 --- 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 + 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 @@ -57,7 +59,7 @@ timestamp = s
[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 --- 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 + + 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 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 \ - ChangeLog.2005 ChangeLog.
[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 --- 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 + + 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 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
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
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: [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.
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? 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.
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] : 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) : > 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
[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
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] : 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) :
Document how to indicate that reloadable objects do not work.
Signed-off-by: Peter Rosin
---
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
+
+ tests: reloadable objects do not work on MSVC, SKIP test.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
+ [cygwin, mingw, pw32, cegcc] : 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) :
+ Document how to indicate that reloadable objects do not work.
+
2010-09-21 Peter Rosin
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: 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
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: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Den 2010-09-20 23:30 skrev Roumen Petrov:
> Peter Rosin wrote:
>> Den 2010-09-18 00:04 skrev Roumen Petrov:
>>> Hi Peter,
>>>
>>> Peter Rosin wrote:
Hi!
need_lib_prefix.at currently fails with MSVC.
>>>
>>> Hmm probably test fail as shared library is build without -no-undefined
>>> flag.
>>>
>>> Did libtool MSC allow creation of shared libraries without -no-undefined ?
>>>
>>> On windows platforms (msc, gcc(mingw*)) may be the test require some PATH
>>> magics.
>>> (as example like func_fix_path from static.at test)
>>
>> You are barking up the wrong tree, since:
>>
>> 1. The test passes on MinGW and Cygwin with gcc, if wouldn't do that if
>> -no-undefined was the cause of the fail.
>
>
>> 2. The patch in the old quoted message makes the test pass on MSVC, which
>> it wouldn't do if -no-undefined was the cause of the fail.
>>
>> "PATH magic" is not relevant if -no-undefined is not passed, since everything
>> should be static in that case (no dlls created).
>
> But the libtool command contain -rpath so the test build shared and static
> libraries .
>
>
> 1) linux native build:
> $ cd .../testsuite.dir/086
> $ strace -f ./main 2>&1 | grep foo
> open("/.libs/tls/i686/libfoo1.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/.libs/tls/libfoo1.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/.libs/i686/libfoo1.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/.libs/libfoo1.so", O_RDONLY) = 3
> open("/.libs/libfoo2.so", O_RDONLY) = 3
> write(1, "libfoo1: 2\nlibfoo2: 3\n", 22libfoo1: 2
> libfoo2: 3
>
> $ ls .../testsuite.dir/086/.libs/
> foo1.la@ foo1.lai foo1.o foo2.o libfoo1.a libfoo1.so* libfoo2.a
> libfoo2.la@ libfoo2.lai libfoo2.so* lt-main* main* mainS.o
>
> Result test pass. Both static and shared libraries are created. The
> executable load shared.
Of course. This is on a "normal" system where every library normally
has a 'lib' prefix and that also has need_lib_prefix="no", because it
really doesn't need the prefix. The test is valid on such "normal"
systems, since it is designed to expose problems on "weird" systems
where need_lib_prefix="unknown", even if the testsuite is running on a
"normal" system. I can only speculate, but I would guess that the test
is there to catch regressions early, before they happen on the "weird"
systems that are not normally used in the development of libtool.
*spends a minutes or two digging in git history*
Let's quote the commit message from when the test was added:
Add a test to simulate a failure visible on systems which
need a library prefix like 'lib', such as BeOS. Fix a number
of bugs exposed by this test in order for it to pass.
Currently the prefix is hardcoded as 'lib', as I am not aware
of systems that require a different prefix:
My patch disables the test on MSVC, because it doesn't like the
hardcoded 'lib' prefix.
Cheers,
Peter
