Re: [PATCH] tests/testsuite.at: Don't use $as_echo
On 3/13/20 4:27 PM, Zack Weinberg wrote:
tests/testsuite.at was using the undocumented internal shell variable
$as_echo to set its own variable $ECHO. M4sh stopped setting this
variable in a patch committed to autoconf development trunk in January
of 2013, which was mostly harmless since there was a fallback setting
for $ECHO. As of March 2020, however, merely mentioning $as_echo in
an m4sh input file will trigger a -Wobsolete warning.
The fix is to promote the fallback setting to be the default setting
and not reference $as_echo anymore. This is safe for the same reason
it was safe for autoconf to stop setting $as_echo -- 'printf %s\n' is a
reliable way to do echoing in all of the shells that are worth worrying
about anymore.
---
tests/testsuite.at | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
ACK.
diff --git a/tests/testsuite.at b/tests/testsuite.at
index d561c2a4..9e33c75a 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -29,8 +29,7 @@ m4_divert_push([PREPARE_TESTS])dnl
: ${AUTOCONF=autoconf}
: ${AUTOMAKE=automake}
: ${AUTORECONF=autoreconf}
-test set = "${ECHO+set}" || ECHO=${as_echo-'printf %s\n'}
-: ${ECHO=$as_echo}
+: ${ECHO='printf %s\n'}
for tool in ACLOCAL AUTOHEADER AUTOCONF AUTOMAKE AUTORECONF; do
if eval \$$tool --version >/dev/null 2>&1; then :; else eval $tool=no; fi
done
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: [PATCH] tests/testsuite.at: Don't use $as_echo
On 3/13/20 4:27 PM, Zack Weinberg wrote:
tests/testsuite.at was using the undocumented internal shell variable
$as_echo to set its own variable $ECHO. M4sh stopped setting this
variable in a patch committed to autoconf development trunk in January
of 2013, which was mostly harmless since there was a fallback setting
for $ECHO. As of March 2020, however, merely mentioning $as_echo in
an m4sh input file will trigger a -Wobsolete warning.
The fix is to promote the fallback setting to be the default setting
and not reference $as_echo anymore. This is safe for the same reason
it was safe for autoconf to stop setting $as_echo -- 'printf %s\n' is a
reliable way to do echoing in all of the shells that are worth worrying
about anymore.
---
tests/testsuite.at | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/testsuite.at b/tests/testsuite.at
index d561c2a4..9e33c75a 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -29,8 +29,7 @@ m4_divert_push([PREPARE_TESTS])dnl
: ${AUTOCONF=autoconf}
: ${AUTOMAKE=automake}
: ${AUTORECONF=autoreconf}
-test set = "${ECHO+set}" || ECHO=${as_echo-'printf %s\n'}
-: ${ECHO=$as_echo}
+: ${ECHO='printf %s\n'}
Side comment: I just realized that:
$ECHO "arg1" "arg2"
is NOT the same as:
echo "arg1" "arg2"
due to use of a newline rather than a space between the arguments. That
is, $ECHO is only safe to use with a single argument. But that fact is
true regardless of this patch, and I did not bother auditing whether we
violate that usage pattern anywhere (perhaps we could make $ECHO expand
to a function call, where the function loudly complains about $# > 1, if
we wanted to make such an audit easier).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: [PATCH 2/2] tests: fix helldl rule generation in _LT_DEMO_SETUP macro
On 3/14/19 5:46 PM, Nikolai Merinov wrote: > * tests/demo.at (_LT_DEMO_SETUP): $@ expanded to empty string during > _LT_DEMO_SETUP expanding. Avoid $@ usage inside m4_define call. It is not necessary to avoid $@, you just merely have to quote it so that m4 doesn't eat it. > --- > tests/demo.at | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/tests/demo.at b/tests/demo.at > index 4eb156cf..a10520b0 100644 > --- a/tests/demo.at > +++ b/tests/demo.at > @@ -121,11 +121,16 @@ else > > # Create a script that says that -dlopen is not supported. > bin_SCRIPTS = helldl > -helldl helldl$(EXEEXT): > - rm -rf $@ > - echo '#! /bin/sh' > $@ > - echo 'echo sorry, -dlopen is unsupported' >> $@ > - chmod +x $@ Writing $[@] is generally sufficient to keep m4 from eating things. If that fails, m4sh supports quadrigraphs, where you can write @S|@@ to get $@ in the resulting file. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Spelling fixes
On 04/23/2017 11:51 PM, Josh Soref wrote: > Can I interest you in: > https://github.com/jsoref/libtool/compare/master...jsoref:spelling?expand=1 > > They can of course be squashed or split/rearranged / have portions > dropped if necessary. It may be easier if you post the actual patches to this list, rather than making us chase a URL (in particular, github is notorious for requiring the use of non-free client-side javascript for the full experience, while posting a patch to the mailing list frees recipients from having to decline non-free software). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: small fix of libtool.m4
On 05/05/2016 11:22 PM, Christian wrote:
> So i found that if you’re running ‘./configure’ on a project that depends on
> libtool, it might happen that the script will end up with the following
> error:
> “/bin/rm: cannot remove 'libtoolT': No such file or directory”. I did some
>
> cfgfile=${ofile}T
> trap "$RM \"$cfgfile\"; exit 1" 1 2 15
> -$RM "$cfgfile"
> +if test -e "$cfgfile" ; then
> + $RM "$cfgfile"
> +fi
That's a TOCTTOU data race. Wouldn't it be better to just use 'rm -f'?
In fact, isn't $RM supposed to be including -f automatically?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/4] Fix func_echo_all inside configure.
On 03/10/2016 02:01 AM, Michael Haubenwallner wrote:
> * m4/libtool.m4 (func_echo_all): Properly get $* through m4.
> ---
> m4/libtool.m4 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index ee292af..7b8b591 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1218,7 +1218,7 @@ fi
> # Invoke $ECHO with all args, space-separated.
> func_echo_all ()
> {
> -$ECHO "$*"
> +$ECHO "@S|@*"
That works. You might also want to try $[]*, for less typing, and
comparable to what we have a few lines earlier:
eval 'cat <<_LTECHO_EOF
$[]1
_LTECHO_EOF'
}
ECHO='func_fallback_echo'
fi
# func_echo_all arg...
# Invoke $ECHO with all args, space-separated.
func_echo_all ()
{
$ECHO "$*"
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 3/4] Use POSIX nm to simplify AIX export_symbols_cmds.
On 03/10/2016 04:29 AM, Peter Rosin wrote: >> + elif test "$lt_cv_nm_interface" = "POSIX nm"; then >> +symxfrm="\\2 $ac_symprfx\\1 \\1" >> +lt_cv_sys_global_symbol_pipe="sed -n -e 's/^[[ >> ]]*$ac_symprfx$sympat[[ ]][[]]*\($symcode$symcode*\)[[ ]][[ >>]]*.*$opt_cr$/$symxfrm/p'" > > Do you really need to handle leading and multiple whitespace here? > Posix, at least as seen here > http://pubs.opengroup.org/onlinepubs/009696699/utilities/nm.html > seems quite clear on no leading space and one space only as separator. No, POSIX states that " " means at least one whitespace (could be multiple; implementations can align at will), and "Δ" means exactly one space character. Since nm didn't use the delta character, the code is correct at looking for multiple whitespace. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Export AIX TLS symbols
On 11/24/2015 09:22 AM, Eric Blake wrote: > On 11/05/2015 10:43 AM, David Edelsohn wrote: >> TLS symbols in AIX display a new, different symbol type in nm output. >> Libtool explicitly creates a list of exported symbols for AIX shared >> libraries using nm and does not recognize the new TLS symbols, so >> those symbols are not exported in AIX shared libraries. >> >> This is a regression for TLS support on AIX where TLS symbols or GCC >> "emultls" symbols were listed as global data and exported. >> >> This patch updates libtool.m4 export_symbols_cmds for AIX in two >> locations so that global symbols labeled with "L" for TLS are included >> in the export list. >> >> * m4/libtool.m4 (export_symbols_cmds) [AIX]: Add global TLS "L" symbols. >> > I'm not an AIX expert, and have no way to test it, but the explanation > is reasonable and I don't see how it can hurt (particularly since the > two changes are under "aix[[4-9]]*)" case blocks). > > I'll go ahead and push this patch (assuming my commit rights are still > active) in 24 hours if no one speaks up to the contrary. Pushed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Export AIX TLS symbols
On 11/05/2015 10:43 AM, David Edelsohn wrote:
> TLS symbols in AIX display a new, different symbol type in nm output.
> Libtool explicitly creates a list of exported symbols for AIX shared
> libraries using nm and does not recognize the new TLS symbols, so
> those symbols are not exported in AIX shared libraries.
>
> This is a regression for TLS support on AIX where TLS symbols or GCC
> "emultls" symbols were listed as global data and exported.
>
> This patch updates libtool.m4 export_symbols_cmds for AIX in two
> locations so that global symbols labeled with "L" for TLS are included
> in the export list.
>
> * m4/libtool.m4 (export_symbols_cmds) [AIX]: Add global TLS "L" symbols.
>
>
> From 71f77c5bd66f09a5bd28614971e8ace1a39da991 Mon Sep 17 00:00:00 2001
> From: David Edelsohn <dje@gmail.com>
> Date: Thu, 5 Nov 2015 09:43:02 -0800
> Subject: [PATCH] Export AIX TLS symbols
>
> ---
> m4/libtool.m4 | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 3335def..2e8c3cf 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -4932,7 +4932,7 @@ m4_if([$1], [CXX], [
> if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
> _LT_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs $convenience | awk
> '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W"))
> && ([substr](\$ 3,1,1) != ".")) { if (\$ 2 == "W") { print \$ 3 " weak" }
> else { print \$ 3 } } }'\'' | sort -u > $export_symbols'
> else
> - _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e
> '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if
> (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W") || (\$ 2
> == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W")
> || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 }
> } }'\'' | sort -u > $export_symbols'
> + _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e
> '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if
> (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2
> == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) {
> if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" }
> else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
> fi
> ;;
> pw32*)
> @@ -5386,7 +5386,7 @@ _LT_EOF
> if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
> _LT_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs $convenience | awk
> '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W"))
> && ([substr](\$ 3,1,1) != ".")) { if (\$ 2 == "W") { print \$ 3 " weak" }
> else { print \$ 3 } } }'\'' | sort -u > $export_symbols'
> else
> - _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e
> '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if
> (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W") || (\$ 2
> == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W")
> || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 }
> } }'\'' | sort -u > $export_symbols'
> + _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e
> '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if
> (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2
> == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) {
> if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" }
> else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
> fi
> aix_use_runtimelinking=no
>
> --
> 2.4.3
>
I'm not an AIX expert, and have no way to test it, but the explanation
is reasonable and I don't see how it can hurt (particularly since the
two changes are under "aix[[4-9]]*)" case blocks).
I'll go ahead and push this patch (assuming my commit rights are still
active) in 24 hours if no one speaks up to the contrary.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.
On 09/23/2015 03:37 PM, Pavel Raiskup wrote: > >>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001 > From: Pavel Raiskup <prais...@redhat.com> > Date: Fri, 18 Sep 2015 23:17:07 +0200 > Subject: [PATCH] libtoolize: fix infinite recursion in m4 > > Some projects use this construct in configure.ac: > > m4_define([version], m4_include([version]) Missing a ) The faulty package used: m4_define([version], m4_include(version)) and the infinite recursion occurred _because_ the usage was underquoted. But as you wrote things here, you have sufficient quoting that you won't trigger infinite recursion. You need to drop the second [] for this to be an accurate representation of the failure. > pkg_version=version > > When the m4_include builtin is undefined (as was done in > libtoolize and extract-trace scripts), the call to this 'version' > macro gone to infinite recursion (until ENOMEM). So rather s/gone to infinite/enters an infinite/ > re-define all potentially dangerous macros by empty strings, > suggested by Eric Blake. > > While we are on it, merge the macro-"blacklist" with similar list > implemented in gettext, except the 'm4_esyscmd'. It's kept s/except the/except for/ > defined because we already trace AC_INIT macro for package > version, while it is often specified by > m4_esyscmd(git-version-gen). Similarly to m4_include, m4_esyscmd > might be opt-in-blacklisted in future. > > References: > http://lists.gnu.org/archive/html/libtool/2015-09/msg0.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580 > With the commit message touched up, it looks okay to me. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.
On 09/19/2015 02:09 AM, Pavel Raiskup wrote: > Hi Hiroyuki Sato, > > On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote: >> This configure.ac is extreme slow on libtool-2.4.6. >> But It run smoothly on libtool-2.4.2. >> https://github.com/groonga/groonga/blob/master/configure.ac > > thanks for reproducer! > > This _really_ looks like issue mentioned [1], though the thread is > believed to be resolved (with existing small slowdown between > libtool-2.4.5 and 2.4.2). Let me CC Robert whether this patch does not > actually fix the "1 sec" slowdown of libtoolize. This looks very much like the same bug that gettext had: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=d75090f2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580 Your proposed solution doesn't seem quite right: > # Disable these macros. > m4_undefine([m4_dnl]) > -m4_undefine([m4_include]) > m4_undefine([m4_m4exit]) > m4_undefine([m4_m4wrap]) > m4_undefine([m4_maketemp]) > +# Rather do not use undefine here because people tend to define > +# macros of the same name as file included in their bodies - which > +# results in infinite recursion. > +m4_define([m4_include], []) I'd recommend that you use the same fix as gettext, and define ALL of these macros to an empty string, rather than special-casing m4_include as the only one that does not get undefined. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] question mark is extended regex for non-GNU grep
On 11/21/2014 05:11 AM, Michael Haubenwallner wrote:
Accepting \? for at-most-once in basic regex is a GNU grep extension,
not accepted by AIX grep for example.
* tests/libtool.at: Need EGREP for ? operator, and ? without \ then.
With EGREP, need one more \ for $.
Or, stick with GREP but use \{0,1\} instead of \?.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 1/2] maint.mk: handle missing git with more grace
On 12/28/2012 03:13 PM, Peter Rosin wrote: * top/maint.mk (no-submodule-changes, public-submodule-commit): Quietly proceed if git is not present. Copyright-paperwork-exempt: yes Signed-off-by: Peter Rosin p...@lysator.liu.se --- top/maint.mk |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Thanks for resending, and sorry for my abysmal reply delay. This one is now simple enough that I have pushed it. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: git-version-gen w/o git
On 12/28/2012 04:45 PM, Peter Rosin wrote: Sure thing, I also rebased them while at it... ...but forgot the script-version. v4 coming up. Sorry for the noise. But sent the wrong patch anyway and also omitted the subject. *blush* v5 coming up. Ugg, I saw v4 and pushed 1/2 before I saw this thread; I'll make sure that I'm using v5 for the 2/2 patch. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 2/2] git-version-gen: add --fallback option to use if git is not present
On 12/28/2012 03:13 PM, Peter Rosin wrote: When building in a git checkout, but from a system lacking git, it is useful to fall back to the version determined when the git checkout was last used from a system sporting git. * build-aux/git-version-gen: Add support for the new option --fallback, which comes into play when there is no $tarball_version_file and git is not working. You didn't really document how to wire up makefiles to properly inject a decent --fallback option into the script; but I'm at least satisfied that this patch in isolation doesn't break existing packages that don't use the --falback option, while leaving the door open for packages that DO want to support the use of --fallback. As I understand it, the idea is that you have a shared folder that can be accessed via multiple machines; on some machines, you have git, and can therefore do a git checkout that populates Makefile with the right information for use as a fallback. On other machines you lack git but can see the .git directory in the shared directory; since it is still a development build and you never ran 'make dist', you still want to have the effect of a devel checkout, rather than building from a tarball, and if all that git was needed for can be injected from the machine that has git installed, then the other machine can benefit from the --falback. I just now noticed v5, so I'll check that out before pushing anything. I will point out that your script introduces yet another instance of a non-portable construct: test -z $fallback Per the Autoconf manual: Posix also says that `test ! STRING', `test -n STRING' and `test -z STRING' work with any string, but many shells (such as Solaris, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4, etc.) get confused if STRING looks like an operator: $ test -n = test: argument expected $ test ! -n test: argument expected $ test -z ); echo $? 0 However, this idiom is already in use elsewhere in git-version-gen, so it should be fixed in an independent patch. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Add Bitrig support
On 11/15/2012 08:29 PM, Brad Smith wrote: On Thu, Sep 20, 2012 at 11:58:20PM -0400, Brad Smith wrote: On Thu, Aug 30, 2012 at 10:56:15AM -0400, Brad Smith wrote: On Tue, Aug 21, 2012 at 11:50:21PM -0400, Brad Smith wrote: The following diff adds support for Bitrig, which is a fork of OpenBSD. Any comments? ping. Is this project dead? No, but it does see rather sporadic bursts of activity when actual maintainers have time free from their daily routines. Your patch hasn't been forgotten, and gentle pings do help. Alas, I'm not one of the actual maintainers. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: git-version-gen w/o git
[adding-gnulib]
On 10/18/2012 06:50 AM, Peter Rosin wrote:
Hi!
I used to use a libtool git checkout from a platform that lacks
git [MSYS], but that broke at some point. I would like something
like the below to unbreak my work flow.
Please?
Cheers,
Peter
diff --git a/Makefile.am b/Makefile.am
index 176325c..3bcb419 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,7 +46,7 @@ EXTRA_LTLIBRARIES =
# Using `cd' in backquotes may print the directory name, use this instead:
lt__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
-git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' '.tarball-version'
+git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' '--fallback'
'$(VERSION)' '.tarball-version'
I'm not sure that makes sense - git-version-gen is ALREADY supposed to
use the contents of .tarball-version as the fallback version.
rebuild = rebuild=:; revision=`$(lt__cd) $(srcdir) $(git_version_gen) |
sed 's|-.*$$||g'`
@@ -128,8 +128,10 @@ $(ltversion_m4): $(ltversion_in) $(dotversion)
done; \
if $$rebuild; then \
rm -f '$@'; \
- if test -f '$(srcdir)/.serial'; then \
- serial=`cat '$(srcdir)/.serial'`; \
+ if test -d '$(srcdir)/.git' git --version /dev/null; then \
+ $(git_commit_count) '$(srcdir)/.serial'; \
+ fi; \
+ serial=`cat '$(srcdir)/.serial'`; \
However, something like this would be useful in libtool.
else \
serial=`$(git_commit_count)`; \
fi; \
And then some support for that in gnulib:
--- gnulib/build-aux/git-version-gen.orig 2012-10-02 17:10:58.935840500
+0200
+++ gnulib/build-aux/git-version-gen 2012-10-18 14:41:57.45846 +0200
@@ -86,6 +86,7 @@
Options:
--prefix prefix of git tags (default 'v')
+ --fallback fallback version to use if \git --version\ fails
--help display this help and exit
--version output version information and exit
@@ -93,12 +94,14 @@
Running without arguments will suffice in most cases.
prefix=v
+fallback=
while test $# -gt 0; do
case $1 in
--help) echo $usage; exit 0;;
--version) echo $version; exit 0;;
--prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
-*)
echo $0: Unknown option '$1'. 2
echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@
# Remove the g in git describe's output string, to save a byte.
v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
v_from_git=1
-else
+elif test -z $fallback || git --version /dev/null; then
v=UNKNOWN
+else
+v=$fallback
Again, I'm not sure if $fallback makes sense, since the .tarball-version
file is already supposed to provide that.
fi
v=`echo $v |sed s/^$prefix//`
--- gnulib/top/maint.mk.orig 2012-10-02 17:10:43.846614700 +0200
+++ gnulib/top/maint.mk 2012-10-18 14:41:53.433652900 +0200
@@ -1327,7 +1327,7 @@
.PHONY: no-submodule-changes
no-submodule-changes:
- $(AM_V_GEN)if test -d $(srcdir)/.git; then \
+ $(AM_V_GEN)if test -d $(srcdir)/.git git --version /dev/null;
then \
diff=$$(cd $(srcdir) git submodule -q foreach \
However, this change probably makes sense in gnulib.
git diff-index --name-only HEAD) \
|| exit 1; \
@@ -1345,7 +1345,7 @@
# cannot be built from a fresh clone.
.PHONY: public-submodule-commit
public-submodule-commit:
- $(AM_V_GEN)if test -d $(srcdir)/.git; then \
+ $(AM_V_GEN)if test -d $(srcdir)/.git git --version /dev/null;
then \
As does this (although wrapping both changes to avoid long lines would
be preferable).
cd $(srcdir)\
git submodule --quiet foreach test '$$(git rev-parse $$sha1)' \
= '$$(git merge-base origin $$sha1)' \
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
On 10/05/2012 10:03 AM, Gary V. Vaughan wrote: Hi Peter, Apologies for having entirely forgotten about the old thread reviewing those patches first time around. And thanks for looking into it. Is there a legal way to get access to Windows and the various flavours of gcc and MSVC that libtool users care about, without spending hundreds of dollars on software I would never use for anything else? It pretty much sucks that everytime I push a well tested (on various Unix varieties) patch, that Windows likes to blow up gratuitously. I don't mind wasting a bit of time checking things on Windows, but I really don't want to also waste money on Microsoft. If you are a fan of virtual machines, it is possible to set up qemu-kvm under Linux to run a default-60-trial of various Windows versions without having to pay for a license. Microsoft also has a documented means of expanding that 60 days into 180 days, which means you can test Microsoft products at no monetary cost at the expense of reinstalling your virtual machine twice per year. Unfortunately, I don't do this often enough myself (my time is more valuable than babysitting a full OS install twice per year, especially if I don't spend much time using that OS), so I don't really have a good link to the current URL for the Microsoft Windows trial versions. I also hear that the 'gnome-boxes' project is trying to make it easier to do this sort of thing (that is, turn it into a gui where you point-and-click on the request to install a Windows trial version, and then everything else from downloading the correct iso and installing it is all automated), but haven't tried that yet. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-141-g4099c12
On 12/17/2011 10:22 PM, Gary V. Vaughan wrote:
libtool: minimise forks per invocation under bash.
* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS): Set these without forking a test script when
running under bash, to avoid a few unnecessary forks.
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+# The += operator was introduced in bash 3.1
+test -z $lt_HAVE_PLUSEQ_OP \
+ test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))
\
This MUST be hidden behind an eval. Otherwise, shells like Solaris
/bin/sh will choke on trying to parse this line:
$ /bin/sh -c 'echo $((${BASH_VERSINFO[0]}*1000 + \
${BASH_VERSINFO[1]}))'
/bin/sh: bad substitution
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: FYI: [PATCH] bootstrap: adopt autoconf echo normalization code.
On 12/18/2011 12:46 AM, Gary V. Vaughan wrote: Pushed as obvious. Dash shipped with Ubutu-11.10 as /bin/sh, among others, still has a crippled echo builtin that mis-handles backslashes. That's an unfair characterization. Rather, dash ships an echo builtin that complies with POSIX by default (which mandates backslash interpretation), while bash ships an echo builtin that ignores backslash by default, but can be made to comply with POSIX via 'shopt -s xpg_echo'. +++ b/build-aux/options-parser @@ -173,6 +173,46 @@ basename='s|^.*/||' nl=' ' +# There are still modern systems that have problems with `echo' mis- +# handling backslashes, among others, so make sure $bs_echo is set to a +# command that correctly interprets backslashes. Again, a mis-characterization of the problem. +# (this code from Autoconf 2.68) + +# Printing a long string crashes Solaris 7 /usr/bin/printf. +bs_echo='\\\' +bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo +bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo +# Prefer a ksh shell builtin over an external printf program on Solaris, +# but without wasting forks for bash or zsh. +if test -z $BASH_VERSION$ZSH_VERSION \ + (test X`print -r -- $bs_echo` = X$bs_echo) 2/dev/null; then + bs_echo='print -r --' + bs_echo_n='print -rn --' Also, I'm not sure that I like the name $bs_echo - it's not namespace clean. I would have expected something more like $lt_echo. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: FYI [PATCH] libtool: minimise forks per invocation under bash.
On 12/18/2011 06:33 AM, Gary V. Vaughan wrote:
Can anyone think of something better than just removing the whole
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by
itself later
on?
Adding an extra eval seems to do the trick:
Yes - hiding behind eval is the only way to use shell extensions that
not all shells will parse.
eval 'test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))'
Of course, a comment about why this eval is needed would be definitely
warranted.
Not that I've looked at the implementation, but isn't eval as bad as a fork on
Windows? (which is the only reason to avoid forks, since they are extremely
cheap on
Unix.)
No. eval doesn't fork.
Or, to be even safer, you could directly poke at $BASH_VERSION instead:
case $BASH_VERSION in
[12].*|3.0.*) ;;
*) lt_HAVE_PLUSEQ_OP=yes;;
esac
Ah, true... I guess I was too focussed on a straight forward one liner, and
missed
the obvious one. D'oh! I'll switch to that and push presently.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: FYI: [PATCH] libtool: make fork minimisation compatible with dash and zsh.
On 12/18/2011 06:49 AM, Gary V. Vaughan wrote:
* build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
$((..)) arithmetic, which causes an error on dash, use a case
based bash version check.
Dash understands $(( )). What it doesn't understand is ${BASH_VERSINFO[0]}.
Solaris /bin/sh understands neither, though, so fixing this is
definitely necessary.
+if test set = ${BASH_VERSION+set}${ZSH_VERSION}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
If you wanted, you could combine those two into a single statement:
: ${lt_HAVE_ARITH_OP=yes} ${lt_HAVE_XSI_OPS=yes}
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
I'm a bit reluctant to do this via a host check;
+# Forks are unreasonably slow under Windows, so we assume that, for at
+# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
+# invocation:
+case $host in
+ *cygwin* | *mingw*)
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
although if cygwin ever follows debian's lead of using dash for faster
/bin/sh, I'm not sure if there is a reliable forkless way to detect dash.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On 12/08/2011 08:04 AM, Bob Friesenhahn wrote:
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that way and ditch the host check.
Thanks!
Is the value of this variable inheritable by subordinate shells, or is
it an internal shell variable which would never be exported to
subordinate shells?
By default, bash sets up $BASH_VERSION as an internal variable, and not
exported. It is unwise for users (or scripts) to export BASH_VERSION to
child processes.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On 12/08/2011 08:29 AM, Charles Wilson wrote:
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm, dash has XSI features (where XSI features covers things like
${var##prefix}). It is only shells like Solaris /bin/sh that lack this
mandatory POSIX feature. Meanwhile, libtool is using more than just XSI
extensions; for example, it is probing for bash's += variable append
extension. I'm not sure how much difference += makes (especially since
it is not shaving on forks, but is reducing O(n^2) malloc behavior for
large piece-wise constructions), but do know that XSI variable usage
definitely shaves a lot of forkes.
As for actual timing comparisons, I have not done any recently.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
On 11/22/2011 02:02 AM, Stefano Lattarini wrote: test a = $b is just as likely to trigger improper evaluation in buggy test(1) implementations as: test $b = a :-o For real? On non-museum pieces? Okay, you've convinced me otherwise. It looks like even buggy versions of test(1) at least have the decency to recognize non-op = arbitrary as always being a string comparison, even if arbitrary looks like an operator (I tried !, =, (, ), -a, and so on). It is only when the first argument looks like an operator that the parser gets confused on what the remaining two arguments should be. And in fact the autconf manual says: Similarly, Posix says that both `test string1 = string2' and `test string1 != string2' work for any pairs of strings, but in practice this is not true for troublesome strings that look like operators or parentheses, or that begin with `-'. (Text that should be probably be expandend to show some examples, *and* to report the exact names and versions of the affected shells). Yes, the autoconf manual could be improved, based on the results of this thread. I tested a bunch of /bin/sh, bash, ksh and zsh versions that I have easy access to, and for all of them, the only way to upset test with leading hypens the first argument. I couldn't do this either (for leading hypens, that is); but see the slighlty more elaborated issues presented above. I can demonstrate a problem with leading hyphen, on Solaris 10 at least: $ touch =; /bin/sh -c 'test -f ='; echo $? /bin/sh: test: argument expected 1 I'll postpone pushing this patch until we get to the bottom of the issue though. I withdraw my objection to the libtool patch. It might not be a common idiom to list the constant first, but who knows? maybe you've started a new trend. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 8/7] syntax-check: fix violations and implement sc_useless_quotes_in_case_branch.
On 11/22/2011 01:21 AM, Gary V. Vaughan wrote: Likewise in the pattern expression; you could further change this to: case $lt_sysroot:$1 in ?*:$lt_sysroot*) Good call, although narrowing the search down to eliminate false positives is a lot trickier in this case! I'm adding the following changeset to this series. Thanks! Actually, no, I take it back. I won't apply that patch since it causes tests to fail for at least dash, bash and ksh. My reading of the opengroup specification agrees with us both that no resplitting should be done in the branch expressions of a case, but there is definitely something odd going on that I don't really understand: Confusing! It seems any backslash escaped character will do, same results with '\S\S' and '\S' as with the dollars above. Yet, with the backslashes removed, all the above print 4 'good's. If it weren't for the fact that ksh, bash and dash all independently behave the same way, I'd have called it a bug... any idea? Oh, I think I understand the issue: $ a=\* $ case b in $a) echo one;; *) echo two;; esac one $ case b in $a) echo one;; *) echo two;; esac two POSIX states: each pattern that labels a compound-list shall be subjected to tilde expansion, parameter expansion, command substitution, and arithmetic expansion, and the result of these expansions shall be compared against the expansion of word, according to the rules described in Section 2.13 (on page 2332) (which also describes the effect of quoting parts of the pattern). which in turn states: If any character (ordinary, shell special, or pattern special) is quoted, that pattern shall match the character itself. The shell special characters always require quoting. So, variable expansion is performed _prior_ to passing the pattern to fnmatch(), but quoting can occur either by \ or by . In the case where $a is unquoted, we are passing fnmatch the string *, but where $a was quoted, the shell is correctly treating * as a literal and passing fnmatch the string \\*. Bash, ksh, and dash are correct; mksh and Solaris 10 (among other shells) are buggy. And I stand corrected - variable expansion in case labels _must_ be quoted if you want to literally match all characters that occur in that variable expansion. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/7] syntax-check: fix violations and implement sc_useless_quotes_in_case.
On 11/21/2011 07:47 AM, Gary V. Vaughan wrote:
Contrary to popular belief, Bourne shell does not resplit case
expressions after expansion, so if there are no shell unquoted
shell metacharacters or whitespace, the quotes are useless.
@@ -568,7 +568,7 @@ func_resolve_sysroot ()
# store the result into func_replace_sysroot_result.
func_replace_sysroot ()
{
- case $lt_sysroot:$1 in
+ case $lt_sysroot:$1 in
?*:$lt_sysroot*)
Likewise in the pattern expression; you could further change this to:
case $lt_sysroot:$1 in
?*:$lt_sysroot*)
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 5/7] syntax-check: fix violations and implement sc_useless_braces_in_variable_derefs.
On 11/21/2011 07:47 AM, Gary V. Vaughan wrote:
Until now, libtool sources have used braced variable names
seemingly at random! Almost always the braces are just noise, so
remove all the unnecessary ones.
* cfg.mk (sc_useless_braces_in_variable_derefs): New syntax
check rule to ensure we only reintroduce braced variable
dereferences if they are followed by a valid variable name
character.
build-aux/general.m4sh, build-aux/git-hooks/commit-msg,
build-aux/ltmain.m4sh, build-aux/options-parser, configure.ac,
libltdl/configure.ac, m4/libtool.m4, m4/ltdl.m4,
m4/ltoptions.m4, tests/defs.m4sh, tests/demo-nopic.test,
tests/depdemo/configure.ac, tests/flags.at, tests/link.test,
tests/objectlist.test, tests/quote.test, tests/static.at: Remove
spurious braces.
+++ b/build-aux/ltmain.m4sh
@@ -152,7 +152,7 @@ exec_cmd=
# Append VALUE to the end of shell variable VAR.
func_append ()
{
-eval ${1}=\$${1}\${2}
+eval $1=\$$1\$2
Not necessarily correct. One of the reasons for using ${1} in any m4
code that comprises the m4_define() definition of a macro is that $1 is
replaced by an argument by m4 in expanding the macro, while ${1} is
preserved unchanged through m4 expansion to be saved for the resulting
shell code. I fear that your global search-and-replace may have been
too eager in m4-related files, but haven't read it closely to check for
sure; even if it didn't, the stylistic convention of ${1} for shell
expansion vs. $1 for m4 expansion made the file slightly easier to maintain.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
On 11/21/2011 07:47 AM, Gary V. Vaughan wrote: To safely use a non-literal first argument to `test', you must always prepend a literal non-`-' character, but often the second operand is a constant that doesn't begin with a `-' already, so always use `test a = $b' instead of noisy `test X$b = Xa'. Not true. test a = $b is just as likely to trigger improper evaluation in buggy test(1) implementations as: test $b = a If you cannot guarantee the contents of $b, then you MUST prefix both sides of the comparison with x or X. Conversely, if you CAN guarantee the contents of $b (for example, if you did b=$?, then you KNOW that b is a numeric tring with no problematic characters), then you might as well use the more idiomatic comparison of variable to constant. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 7/7] syntax-check: fix violations and implement sc_prohibit_sed_s_comma.
On 11/21/2011 07:47 AM, Gary V. Vaughan wrote: I like to name temporary directories that I will remove shortly with two leading commas so that they sort lexicographically at the top of `ls' output. Now, `./configure --prefix=`pwd`/,,inst' works again, for the first time in several years. Try to use `|' as the default separator wherever possible, otherwise something else that doesn't occur in the substitution expression. I'm in favor of this one. In particular, one of the reasons that autoconf documents | as superior to , is that | has to be shell-quoted to be used, while , does not, which means a user is more likely to have a filename containing comma than they are to have a filename containing a pipe. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/7] syntax-check: fix violations and implement sc_useless_quotes_in_assignment.
On 11/21/2011 01:59 PM, Roumen Petrov wrote: Gary V. Vaughan wrote: [SNIP] diff --git a/bootstrap.conf b/bootstrap.conf index 6f0f0c3..c3491b5 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -77,13 +77,13 @@ gnulib_modules=' # Extra gnulib files that are not in modules, which override files of # the same name installed by other bootstrap tools. -gnulib_non_module_files=$gnulib_non_module_files' +gnulib_non_module_files=$gnulib_non_module_files' doc/COPYINGv2 doc/fdl.texi [SNIP] hmm, origin is only with end apostrophe . That's not a problem. It's merely changing: var=$expanded'literal' to the equivalent var=$expanded'literal' where the literal portion includes newline characters. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/15/2011 09:22 PM, Gary V. Vaughan wrote: Hi Chuck, Eric, Thanks both for the review! On 15 Nov 2011, at 23:07, Charles Wilson wrote: On 11/15/2011 7:53 AM, Gary V. Vaughan wrote: tests/mdemo/Makefile.am -## use @LIBLTDL@ because some broken makes do not accept macros in targets +## use $(LIBLTDL) because some broken makes do not accept macros in targets This comment now makes zero sense. If you are now forcing the following rule: +$(LIBLTDL): $(top_distdir)/libtool \ then (a) remove the comment completely, and (b) document somewhere that we now require non-broken make which DOES allow $(macros) in targets. + - At some point we were supporting some undetermined `broken make', as +evidenced by having carried the following code since 2003: + + ## use @LIBLTDL@ because some broken makes do not accept macros in + ## targets, we can only do this because our LIBLTDL does not contain + ## $(top_builddir) + @LIBLTDL@: $(top_distdir)/libtool \ + ... By the way, such make implementations (that don't work with $(macros) in targets) exist: https://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html At least IRIX and HP-UX vendor make fail to handle macros in the target. + +However, we've also had *many* cases of macros in targets for just as +long, so most likely we never fully supported makes allegedly broken +in this way. As of this release, we explicitly no longer support +make implementations that do not accept macros in targets. I suppose we can resuscitate make portability if anyone complains loudly enough. We may want to also ask on the automake list if this is still a real limitation, or whether automake has given up on worrying about this as well. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/16/2011 06:04 PM, Gary V. Vaughan wrote: Right, and even when I wrote the dubious comment quoted above in 2003, other parts of libtool were still using macro expansions in make targets, so I think the whole thing is probably a red herring. Libtool has never fully supported any make that can't deal with macros in targets, and we've never received a complaint or bug report, which makes me think that if such a make exists, no one wants to use it with libtool, so we can safely ignore the whole thing. The NEWS entry I wrote for this commit is purely for future repo archaeology. Then it's not NEWS-worthy. It's worth keeping that analysis in the git commit message (as you say, for repo archaeology), but let's limit it to just there, rather than potentially causing users to worry about some perceived loss of portability when they read NEWS. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 03/25] syntax-check: fix violations and re-enable sc_cast_of_argument_to_free.
On 11/15/2011 05:53 AM, Gary V. Vaughan wrote: * cfg.mk (local-checks-to-fix): Remove sc_cast_of_argument_to_free from list of disabled checks. * libltdl/config/ltmain.m4sh, libltdl/libltdl/lt__alloc.h, libltdl/lt__dirent.c: Casting argument to free is never necessary. Not true; sometimes it is necessary to cast away const. That is: const char *str = malloc(n); free(str); will cause a noisy compile, where the cast solves things. However, it is arguable that anyone assigning malloc() results to a const pointer is not following const-correctness rules in the first place. So if things still compile with warnings, meaning we weren't ever passing a const pointer to free in the first place within libtool, _and_ we are sure no one else was using our [X]FREE macros as a way to cast away the const in their code, then I'm okay with this patch. (The alternative is to add a syntax-check exception in cfg.mk for the particular files where we define the macros that cast away const). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.
On 11/15/2011 05:53 AM, Gary V. Vaughan wrote: * cfg.mk (local-checks-to-fix): Remove sc_cast_of_x_alloc_return_value from list of disabled checks. That check is only useful for pure C projects. If the intention is that libtool can be compiled under both C and C++, then C++ requires that you cast the result of allocation functions (only C lets you get away with going from void* to any other pointer without cast). Are we sure that no one tries to compile libtool with a C++ compiler? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/15/2011 09:49 AM, Charles Wilson wrote: On 11/15/2011 7:53 AM, Gary V. Vaughan wrote: tests/mdemo/Makefile.am -## use @LIBLTDL@ because some broken makes do not accept macros in targets +## use $(LIBLTDL) because some broken makes do not accept macros in targets This comment now makes zero sense. If you are now forcing the following rule: +$(LIBLTDL): $(top_distdir)/libtool \ then (a) remove the comment completely, and (b) document somewhere that we now require non-broken make which DOES allow $(macros) in targets. As an alternative, revert this change, and instead add a setting of _makefile_at_at_check_exceptions in cfg.mk that exempts just @LIBLTDL@. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] libtoolize: simplify file-copying and -linking call-graph.
On 11/14/2011 04:04 AM, Gary V. Vaughan wrote: This series of changesets are either necessary for, or at least make the application of the directory move patches coming in the next set as straight forward as possible. It turns out that we haven't needed to fork a tar process for every file-copy for about 4 years now. With that knowledge it's easy to reduce the complexity of the surrounding functions somewhat. I'll apply in 72 hours, along with addressing any feedback I get in the mean time. @@ -112,8 +110,7 @@ M4SH_GETOPTS( CP=func_echo_all $CP test -n $LN_S LN_S=func_echo_all $LN_S MKDIR=func_echo_all $MKDIR - RM=func_echo_all $RM - TAR=func_echo_all $TAR], + RM=func_echo_all $RM], My only concern is whether existing projects may have been (inadvertently) relying on $TAR to be set on their behalf by using libtool. The reason I ask is that I know of at least one case where a project was using libtool, but manually setting $RM itself to a value different than libtool's default, which in turn caused libtool to emit a warning: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=8a93dafc5 That is, dropping $TAR is a user-visible change, so we either need to document it in NEWS that it is intentional, or we need to keep providing $TAR (even though we no longer use it) to keep our namespace pollution constant, all so that users upgrading to newer libtool don't complain about an undocumented change. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
On 11/01/2011 08:19 AM, Gary V. Vaughan wrote: This next series of changesets is the beginning of modelling the directory and filenaming conventions of Libtool to match what is done by other prominent GNU projects... this means that gnulib scripts will require less tweaking and configuration, so we can use them in the configuration in which they have been most widely tested and debugged. Also, it makes everything look more familiar to anyone coming from another GNU project who is hoping to generate some patches for us... and every little thing we can do to reduce friction in that process is a net win as far as I am concerned. I've attached the full patch which is ridiculously large for a simple directory move and fixing the fallout in the files that care. Next time, when sending a file rename patch, consider using 'git format-patch/send-email -M -C', which finds moves and renames and compresses them into a much smaller patch output that names just the old and new file name and any incidental differences between the two files (if I understand git correctly, the only reason the smaller patch is not default is because it takes a bit more processor time to determine file similarity and because it was not understood by patch(1) back in the days when git used patch rather than its own tools for parsing changesets; but I don't ever notice the difference, and definitely appreciate the smaller diffs). Or make those options permanent for your git setup, with 'git config --global diff.renames true'. At any rate, I'm certainly in favor of this series, in the name of easier maintenance, although I didn't review it closely. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 01/10] Add -shortname option.
On 04/15/2011 06:59 AM, KO Myung-Hun wrote: OS/2 limits a length of a DLL base name up to 8 characters. If a name of a shared library is longer than 8 characters, OS/2 cannot load it. So the option to specify a short name is needed. --- NEWS |1 + doc/libtool.texi |4 libltdl/config/ltmain.m4sh | 11 +++ libltdl/m4/libtool.m4 | 38 ++ 4 files changed, 50 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 90d14b7..566eeb1 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,7 @@ New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team: - The --with-pic configure option now supports a list of comma-separated package names. This can be used to build some static libraries with PIC objects while building others with non-PIC objects. + - Added -shortname option to specify a short name for a DLL (OS/2 only) Long options should start with --, not -, per GNU coding conventions (gcc is an exception, but libtool should not be). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Rebuild menus in the manual.
On 11/14/2010 10:10 AM, Ralf Wildenhues wrote:
I would like to push this patch that has emacs-rebuilt menus.
They actually typeset a bit worse than the hand-written ones
(see e.g. the last hunk) but I think that doing something
automatically is better than doing it manually, and if there
is pain involved then we should consider trying to shorten the
names of the nodes in question. (If we do, we need to remember
to add entries to html_node/.symlinks in the web cvs, so the old
URLs remain valid.)
You can also add an @anchor{old name} next to the new name, to avoid
having to create manual symlinks (the existence of the anchor will mean
that the old name still goes somewhere in the web). For example, see
how autoconf.texi @node Specifying Target Triplets has an
@anchor{Specifying Names}.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [patch] allow --with-pic to accept package names
On 10/22/2010 03:02 PM, Peter Rosin wrote: There is never any need to quote the right-hand side of assignments, unless you have literal whitespace in them. If you do a=foo; b= bar; c=$a$b; d=$c both $c and $d will be foo bar. See 'Shell Substitutions' in the 'Portable Shell' chapter in the autoconf manual. In fact, there's sometimes a requirement that you must NOT quote the right-hand side of assignments if you care about portability to buggy shells: a=`echo b c` is non-portable, but a=`echo b c` reliably assigns b c to $a in all shells. I just stated tangential info since the problematic quoting needed fixing, and since that is fixed I don't see any need to do a re-spin just because of this. Agreed. -- 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.
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.
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
[PATCH] build: ship autobuild.m4, to reduce bootstrap requirement
Shipping a copy of autobuild.m4 makes it so that users need not
pre-install autobuild just for aclocal to find the macro AB_INIT.
* libltdl/m4/.gitignore: Drop autobuild.m4.
* libltdl/m4/autobuild.m4: New file, copied from autobuild.
* configure.ac (AB_INIT): Unconditionally call it.
Signed-off-by: Eric Blake ebl...@redhat.com
---
Be sure to *not* list autobuild.m4 anywhere else, e.g., in Makefile.am.
It is picked up automatically. You can make the AB_INIT call in
configure.ac unconditional, but then again, no loss in leaving it as it
is.
I've tested that 'make dist' does include autobuild.m4.
ChangeLog |7 +++
configure.ac|3 +--
libltdl/m4/.gitignore |1 -
libltdl/m4/autobuild.m4 | 40
4 files changed, 48 insertions(+), 3 deletions(-)
create mode 100644 libltdl/m4/autobuild.m4
diff --git a/ChangeLog b/ChangeLog
index 8ed47f7..d468552 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-09-20 Eric Blake ebl...@redhat.com
+
+ build: ship autobuild.m4, to reduce bootstrap requirement
+ * libltdl/m4/.gitignore: Drop autobuild.m4.
+ * libltdl/m4/autobuild.m4: New file, copied from autobuild.
+ * configure.ac (AB_INIT): Unconditionally call it.
+
2010-09-20 Peter Rosin p...@lysator.liu.se
Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/configure.ac b/configure.ac
index 0fcf109..131cd3b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -138,8 +138,7 @@ AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz
color-tests parallel-tests])
# string for this build.
: ${autobuild_mode=default}
AB_VERSION=AC_PACKAGE_VERSION ($TIMESTAMP)
-m4_ifdef([AB_INIT],
-[AB_INIT([$autobuild_mode])])
+AB_INIT([$autobuild_mode])
dnl We use m4sh to generate libtool's portable shell scripts
diff --git a/libltdl/m4/.gitignore b/libltdl/m4/.gitignore
index 81a1059..0b52c5c 100644
--- a/libltdl/m4/.gitignore
+++ b/libltdl/m4/.gitignore
@@ -1,2 +1 @@
ltversion.m4
-autobuild.m4
diff --git a/libltdl/m4/autobuild.m4 b/libltdl/m4/autobuild.m4
new file mode 100644
index 000..93ccb54
--- /dev/null
+++ b/libltdl/m4/autobuild.m4
@@ -0,0 +1,40 @@
+# autobuild.m4 serial 7
+dnl Copyright (C) 2004, 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
+dnl Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl From Simon Josefsson
+
+# Usage: AB_INIT([MODE]).
+AC_DEFUN([AB_INIT],
+[
+ AC_REQUIRE([AC_CANONICAL_BUILD])
+ AC_REQUIRE([AC_CANONICAL_HOST])
+
+ if test -z $AB_PACKAGE; then
+AB_PACKAGE=${PACKAGE_NAME:-$PACKAGE}
+ fi
+ AC_MSG_NOTICE([autobuild project... $AB_PACKAGE])
+
+ if test -z $AB_VERSION; then
+AB_VERSION=${PACKAGE_VERSION:-$VERSION}
+ fi
+ AC_MSG_NOTICE([autobuild revision... $AB_VERSION])
+
+ hostname=`hostname`
+ if test $hostname; then
+AC_MSG_NOTICE([autobuild hostname... $hostname])
+ fi
+
+ ifelse([$1],[],,[AC_MSG_NOTICE([autobuild mode... $1])])
+
+ date=`TZ=UTC0 date +%Y%m%dT%H%M%SZ`
+ if test $? != 0; then
+date=`date`
+ fi
+ if test $date; then
+AC_MSG_NOTICE([autobuild timestamp... $date])
+ fi
+])
--
1.7.2.3
Re: [PATCH] build: ship autobuild.m4, to reduce bootstrap requirement
On 09/20/2010 12:44 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Mon, Sep 20, 2010 at 08:13:25PM CEST: Shipping a copy of autobuild.m4 makes it so that users need not pre-install autobuild just for aclocal to find the macro AB_INIT. * libltdl/m4/.gitignore: Drop autobuild.m4. * libltdl/m4/autobuild.m4: New file, copied from autobuild. * configure.ac (AB_INIT): Unconditionally call it. OK thanks! Pushed. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
[PATCH] maint: drop autobuild requirement
* HACKING: Update. Signed-off-by: Eric Blake ebl...@redhat.com --- I'm pushing this under the obvious rule, given that the whole point of my previous patch was to remove this dependency, and since this is a docs-only patch. ChangeLog |3 +++ HACKING |4 +--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index d468552..ceb193c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,8 @@ 2010-09-20 Eric Blake ebl...@redhat.com + maint: drop autobuild requirement + * HACKING: Update. + build: ship autobuild.m4, to reduce bootstrap requirement * libltdl/m4/.gitignore: Drop autobuild.m4. * libltdl/m4/autobuild.m4: New file, copied from autobuild. diff --git a/HACKING b/HACKING index d36b7f0..977be10 100644 --- a/HACKING +++ b/HACKING @@ -602,9 +602,7 @@ or obtained by writing to the Free Software Foundation, Inc., (esp. bug-libtool) for outstanding bug reports also in the list of pending moderation requests. -* Make sure you have wget, xz, and autobuild installed. aclocal should be - able to find autobuild.m4; or you can install it into the tree with - aclocal -I libltdl/m4 --install +* Make sure you have wget and xz installed. * Make sure your locale is sane, e.g. by exporting LC_ALL=C. -- 1.7.2.3
Re: [PATCH] maint: ship .xz, not .lzma
On 09/14/2010 07:58 AM, Eric Blake wrote: * configure.ac (AM_INIT_AUTOMAKE): Prefer better file format. * Makefile.maint (git-release, git-dist, prev-tarball) (new-tarball, diffs): Use correct extension. * HACKING: Update instructions. Hmm - I mentioned it in ChangeLog, but hadn't yet saved the buffer when I did 'git commit'. I squashed this in before actually pushing (thank heavens for 'git push --dry-run' and double checking what I was about to do). diff --git c/HACKING w/HACKING index e9184f2..d36b7f0 100644 --- c/HACKING +++ w/HACKING @@ -602,7 +602,7 @@ or obtained by writing to the Free Software Foundation, Inc., (esp. bug-libtool) for outstanding bug reports also in the list of pending moderation requests. -* Make sure you have wget, lzma, and autobuild installed. aclocal should be +* Make sure you have wget, xz, and autobuild installed. aclocal should be able to find autobuild.m4; or you can install it into the tree with aclocal -I libltdl/m4 --install -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: tests: avoid empty AT_DATA contents, for zsh.
On 09/12/2010 09:30 AM, Ralf Wildenhues wrote: This fixes the remaining testsuite failures with zsh 4.3.10 on FreeBSD. catfileEOF EOF produces an empty file with sh, but a file containing a newline with zsh, even after 'emulate sh'. autoconf.texi patch coming up too, I guess. Ouch - that's a nasty bug. Have you reported it to the zsh list yet? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: tests: avoid empty AT_DATA contents, for zsh.
On 09/13/2010 08:16 AM, Eric Blake wrote: On 09/12/2010 09:30 AM, Ralf Wildenhues wrote: This fixes the remaining testsuite failures with zsh 4.3.10 on FreeBSD. catfileEOF EOF produces an empty file with sh, but a file containing a newline with zsh, even after 'emulate sh'. autoconf.texi patch coming up too, I guess. Ouch - that's a nasty bug. Have you reported it to the zsh list yet? Hmm, rather than fixing all _our_ uses of AT_DATA, but still having the problem for other clients, why not instead fix AT_DATA to special-case the empty argument to do the right thing for everyone? Don't apply this patch, and I'll help come up with an alternative. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: tests: avoid empty AT_DATA contents, for zsh.
[adding bug-autoconf] On 09/13/2010 08:18 AM, Eric Blake wrote: On 09/13/2010 08:16 AM, Eric Blake wrote: On 09/12/2010 09:30 AM, Ralf Wildenhues wrote: This fixes the remaining testsuite failures with zsh 4.3.10 on FreeBSD. catfileEOF EOF produces an empty file with sh, but a file containing a newline with zsh, even after 'emulate sh'. autoconf.texi patch coming up too, I guess. Ouch - that's a nasty bug. Have you reported it to the zsh list yet? Hmm, rather than fixing all _our_ uses of AT_DATA, but still having the problem for other clients, why not instead fix AT_DATA to special-case the empty argument to do the right thing for everyone? Don't apply this patch, and I'll help come up with an alternative. Oops - I thought your patch was for autoconf when I asked you not to apply the patch. On re-reading this, I see that it is a libtool patch instead. Go ahead and apply the libtool patch, since you can't guarantee (or don't want to limit yourself to) a new enough autoconf. Meanwhile, in parallel, I will be patching autoconf to make AT_DATA explicitly allow empty files in 2.68. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
[PATCH] maint: ship .xz, not .lzma
* configure.ac (AM_INIT_AUTOMAKE): Prefer better file format. Signed-off-by: Eric Blake ebl...@redhat.com --- Any objections to this patch? xz is a more robust successor to lzma. ChangeLog|5 + configure.ac |2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 39c3e7a..7778ace 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-09-13 Eric Blake ebl...@redhat.com + + maint: ship .xz, not .lzma + * configure.ac (AM_INIT_AUTOMAKE): Prefer better file format. + 2010-09-13 Ralf Wildenhues ralf.wildenh...@gmx.de doc: avoid long lines in input and output, indexing fixes. diff --git a/configure.ac b/configure.ac index d36adde..0fcf109 100644 --- a/configure.ac +++ b/configure.ac @@ -127,7 +127,7 @@ AC_SUBST([package_revision]) dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue. -AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-lzma color-tests parallel-tests]) +AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests]) ## - ## -- 1.7.2.2
git log - changelog [was: [PATCH] Path conversion documentation]
[adding bug-gnulib] On 09/02/2010 03:00 PM, Charles Wilson wrote: IF we want to use gitlog to create the ChangeLog, then either of these is fine with me. However, see below. iii) fix the gitlog entries -- if that's even viable? I don't think (iii) will work. You can play all sorts of games with filter-branch, but...I managed to screw up three different git clones before I gave that up as a bad idea (I was trying to fix the author of a commit that was not the final entry). Recent git has added the notion of annotations; we could use a specific annotation namespace for replacement ChangeLog messages to be used for any commit where we typo'd the original commit log (or left out credit for a contributor, etc.). But since Jim was the one that developed the gitlog to changelog conversion tool, he's more familiar with what it would take, and whether it even makes sense to require a new enough git version to exploit commit annotations as a means of fixing ChangeLog entries. Comments? It does seem like gitlog and ChangeLog duplicate the same info, so it would definitely be nice to reduce dvlpr workload. However, I have noticed that you /just can't/ do the following -- which is actually required by the GCS: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter... Steve Committer Rewrite...=== can't do this Well, if you go by git's Signed-off-by tags as a way of generating those lines, it would be possible. Also, this would be an argument where annotations could serve to fill in the gap. * file (func): comment Signed-off-by: Steve Committer Rewrite... === Also, for trivial commits without a copyright assignment, the GCS says you should do this: === 2010-09-02 Sally No Assignment... (tiny change) Again, something that annotations could cover. * file (func): comment Signed-off-by: Mark Committer... === Now, MAYBE the committer can do that by munging the --author='...'; I've never tried and I'm not sure how thoroughly git checks the --author argument. You can munge anything before the email, but can't add (tiny change) afterwards (in other words, git hard-codes the email address to be last). I'd rather not munge --author, since 'git shortlog' would be noticeably worse with annotations like that. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: git log - changelog
On 09/02/2010 03:16 PM, Charles Wilson wrote: On 9/2/2010 5:08 PM, Eric Blake wrote: On 09/02/2010 03:00 PM, Charles Wilson wrote: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter... Steve Committer Rewrite... === can't do this Well, if you go by git's Signed-off-by tags as a way of generating those lines, it would be possible. Ah, but then how do you distinguish between a chain of Signed-off-by labels -- as in the Linux kernel, where various subsystem maintainers also have to sign off on patches, in the sense of I certify that this is OK, and it has proper approvals, and has been reviewed, (FSF: and the author has a copyright assignment). vs. and I modified the actual contents of the patch a little bit The git pages are clear that S-O-B has project-dependent interpretation. Coreutils currently doesn't even use it (the only people with commit privileges to the master coreutils.git have FSF copyright, and it is assumed that they are each trustworthy enough to do due diligence in verifying that patches from other contributors meet copyright rules, without relying on any markup in the commit message itself). But if we wanted, we could adopt a policy that S-O-B on GNU projects using the gitlog-to-changelog conversion implies (partial) authorship, above and beyond the --author. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
On 08/31/2010 12:43 AM, Gary V. Vaughan wrote: From: Gary V. Vaughang...@gnu.org * libltdl/config/announce-gen.m4sh: Add support for gnulib announce-gen options, previously missing from our m4sh implementation, and enforce specifying --gnulib-version when `gnulib' is listed in --bootstrap-tools. Are you planning on swapping over to gnulib's announce-gen once gnulib is fully integrated? And in the meantime, what good does it do to have a --gnulib-version option if we aren't using gnulib yet? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: ${var:+quo ted} and similar, inside unquoted here-docs
[adding bug-bash]
On 08/29/2010 08:48 AM, Ralf Wildenhues wrote:
With Solaris 10 sh (and others):
catEOF
${var-quo ted}
EOF
quo ted
Whereas with bash (and others):
quo ted
Ouch. New one to me. ksh, zsh, and dash do not echo the quotes, so I'm
thinking it may be a bash bug; hence the cc.
Eric, did you have this in your recent autoconf.texi additions already?
It can be a problem for all of the stuff that gets expanded into here
documents.
Now, for the good news - the bug is easy to work around, while still
using a here-doc. A here-doc is parsed in a different context (no word
splitting, no filename expansion) than normal, so /bin/sh does NOT have
the bug related to bad parameter messages if you omit the quotes.
All shells that I had access to reliably gave the same output for:
cat EOF
${var-quo ted}
EOF
quo ted
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: ${var:+quo ted} and similar, inside unquoted here-docs
On 08/29/2010 08:59 AM, Ralf Wildenhues wrote:
-AS_BOX([Configuring AC_PACKAGE_TARNAME${TIMESTAMP:+ (Build:$TIMESTAMP)}
AC_PACKAGE_VERSION])
+timestamp_string=
+if test -n $TIMESTAMP; then
+ timestamp_string= (Build:$TIMESTAMP)
+fi
Why not:
timestamp_string=${TIMESTAMP:+ (Build:$TIMESTAMP)}
instead of the if/fi?
+AS_BOX([Configuring AC_PACKAGE_TARNAME$timestamp_string AC_PACKAGE_VERSION])
Or, since we know the workaround is to remove the inside here-docs,
why not:
AS_BOX([Configuring AC_PACKAGE_TARNAME${TIMESTAMP:+ (Build:$TIMESTAMP)}
AC_PACKAGE_VERSION])
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: ${var:+quo ted} and similar, inside unquoted here-docs
On 08/30/2010 08:57 AM, Eric Blake wrote:
[adding bug-bash]
On 08/29/2010 08:48 AM, Ralf Wildenhues wrote:
With Solaris 10 sh (and others):
catEOF
${var-quo ted}
EOF
quo ted
Whereas with bash (and others):
quo ted
Ouch. New one to me. ksh, zsh, and dash do not echo the quotes, so I'm
thinking it may be a bash bug; hence the cc.
Sorry about that; I read my results wrong. bash is consistent with
everyone else, and only /bin/sh was the outlier. No bug in bash, after all.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: ${var:+quo ted} and similar, inside unquoted here-docs
On 08/29/2010 08:59 AM, Ralf Wildenhues wrote:
+++ b/configure.ac
@@ -113,7 +113,11 @@ case $lt_alpha in
TIMESTAMP=
;;
esac
-AS_BOX([Configuring AC_PACKAGE_TARNAME${TIMESTAMP:+ (Build:$TIMESTAMP)}
AC_PACKAGE_VERSION])
According to 'git gui blame configure.ac', libtool has been using
${a:+b} since July 2004, with no bug reports about a bad substitution
from a less-than-stellar shell (in fact, libtool's use dates back to the
days when autoconf didn't even enforce shell function support). Thanks
for this additional anecdotal evidence that autoconf's recent move to
document that : is reliable for null substitutions is reasonable for all
shells that support functions.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: tests: skip -Wall -Werror with Tru64 cc in cwrapper test.
On 08/30/2010 03:06 PM, Ralf Wildenhues wrote: http://autobuild.josefsson.org/libtool/log-201008291316239205000.txt Don't you love those permissive compilers where only the linker fails later with: libtool: link: /opt/fsw/bin/cc -g -Wall -Werror -o .libs/usea usea.o ./.libs/liba.so -rpath /foo Invalid flag usage: Wall, -Wx,-option must appear after -_SYSTYPE_SVR4 ld: Usage: ld [options] file [...] stdout: ./../libtool/tests/cwrapper.at:77: exit code was 1, expected 0 Does this have any ramifications for autoconf's AC_LANG_WERROR? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH] Autotest 2.62 bug?
On 08/09/2010 05:14 AM, Gary V. Vaughan wrote: Hallo Ralf, The following patch makes it possible to bootstrap libtool.git master with Autoconf 2.62, though it is not necessary when using a newer Autoconf. Unfortunately I don't know my way around the innards of Autotest well enough to be able to figure out what the problem is, though with time it should be possible to bisect to the changeset that fixes it I suppose. Probably due to handling of unquoted # within the test name. Have you tried the quadrigraph @%:@ instead, which should work around the bug in the older 2.62? # Don't bother with additional XSI checks unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool /dev/null 21 || (exit 77)]) +fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool /dev/null 21 || exit 77 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Support new platform Andestech Platform
On 08/06/2010 06:53 AM, Thomas YS Liu wrote: *1. Modify config.sub* *1.1 Modify config.sub file* for individual package This step helps the autoconf tool http://www.gnu.org/software/autoconf/recognizing the Andes architecture and machine type. You can follow the diff file below to modify the corresponding field in your package’s config.sub file. *$ diff -u config.sub.orig config.sub* Please send patches to config.sub upstream to config-patc...@gnu.org, per the directions embedded in config.sub. No need to cc all of these downstream projects when doing so. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Fix testsuite errors due to shell quoted parameter expansion issue.
[please don't top-post on technical lists]
On 08/04/2010 09:18 AM, John Lumby wrote:
Re the statement
since $e is quoted, it must not be elided
I don't think that is correct. In fact $e *must* be elided - because
you juxtaposed it with the next token.eliding and quoting are orthogonal.
Your statement is confusing to me. Here, in more detail, is exactly
what I meant (and what I though I implied in the first case):
The word in question is '$e$f' before either parameter substitution,
or word splitting, or quote elision.
After parameter substitution, you are left with ' val', where a
portion of the string was originally quoted, but you also had a portion
of the string that was unquoted. Only the ' val' portion of the result
is subject to word splitting.
Because $e is quoted, the resulting empty string must not be elided
during word splitting.
Therefore, the result after word splitting MUST be the two words ''
and 'val'; then you apply quote elision and are left with two words: ''
and 'val'.
What you appear to be be expecting is that the effect of quoting one token
should somehow have some effect on interpretation of a special character
(blank) in a subsequent unquoted token. I don't think that is expected
behaviour. The quoting of $e has the effect of quoting any special
characters inside *it*, of which there are none. your blank is unquoted.
Then word-spilling proceeds.
No, what I expect is that within a single word, the quoted portion of
the word must not be elided during word splitting, except in the special
case of $@.
What I find interesting is this
bash -c 'declare -i length; f= val e=;concat=$e$f; length=${#concat};
echo length= $length'
4
Why do you find that interesting? There is NO word splitting in
assignment contexts, so the effect of
concat=$e$f
is the same as if you had done
concat=$e$f
or
concat=$e$f
in all three cases, concat is assigned the value ' val', which is indeed
length 4.
But it is unrelated to the bash bug at hand, which is that when $e$f
is in a context subject to word splitting, then it must result in the
two words '' and 'val', not the single word 'val'.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Fix testsuite errors due to shell quoted parameter expansion issue.
[adding autoconf to document some shell bugs]
On 08/03/2010 02:32 PM, Ralf Wildenhues wrote:
Interesting shell unportability:
$ bash -c 'f= val e=; echo $e$f'
val
$ ksh -c 'f= val e=; echo $e$f'
val
ksh93, dash, zsh all do it like ksh. Is that a bug in bash?
Yes; adding bug-bash accordingly. According to POSIX:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
After parameter expansion ( Parameter Expansion ), command substitution
( Command Substitution ), and arithmetic expansion ( Arithmetic
Expansion ), the shell shall scan the results of expansions and
substitutions that did not occur in double-quotes for field splitting
and multiple fields can result.
Since $f is not quoted, its expansion must undergo field splitting. But
since $e is quoted, it must not be elided even though empty. The
result must be _two_ fields, as if you had done echo '' 'val'.
But it is _also_ a bug in zsh; adding zsh-workers accordingly.
$ zsh -cvx 'f= val e=; echo $e$f'
+zsh:1 f=' val' e=''
+zsh:1 echo ' val'
val
Oops - zsh only passed one argument to echo, with a leading space,
instead of passing an empty argument and letting echo supply the space.
ksh93, pdksh, and dash get it right (although dash doesn't use quotes
in -vx output, hence my use of n() to force things to tell; n() is
another way to expose the bash and zsh bugs).
$ ksh -cvx 'n() { echo $#; }; f= val e=; n $e$f'
n() { echo $#; }; f= val e=; n $f+ f=' val'
+ e=''
+ n '' val
+ echo 2
2
And meanwhile, I found a ksh93 parsing bug (don't know where to report
that):
$ ksh -c 'a(){ echo hi; }; a'
ksh: syntax error at line 1: `}' unexpected
$ ksh -c 'a() { echo hi; }; a'
hi
$ bash -c 'a(){ echo hi; }; a'
hi
$ /bin/sh -c 'a(){ echo hi; }; a'
hi
ksh is the only shell that requires a space between the ) and {, even
though the ) is a metacharacter and should not need trailing space (even
Solaris /bin/sh got that right).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 12:52 AM, Gary V. Vaughan wrote:
i=$((i+1))
I think we can't rely on the availability of $((expr)) :(
Is there any shell that supports XSI but not $(()), seeing as how both
are mandated by POSIX? But we've already come up with better
alternatives, so this is a moot point.
However, I think that will be considerably slower than the ${1:0:2}/${1:2}
approach. But we're probably talking microseconds... so I'm open to
advice on whether to use bash/ksh variable substrings exclusively (as per
current master); XSI exclusively (although we make heavy use of += already
if it is available, so not really exclusively); or to prefer substring
syntax over the XSI syntax if either or both are available, falling back
on sed if necessary?
Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
support, but that will have to wait until after autoconf 2.66.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 12:35 PM, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
I think m4sh can simply use code like
if ( eval '$smart_works' ) /dev/null 21; then
func_foo () { smart code; }
else
func_foo () { safe code; }
fi
for code run a handful of times, without need for extra m4 magic, it's
just that libtool is easily run hundreds of times in a typical large
software build so it warrants optimization.
In that case might the retarded shell choke and die as it parses 'smart
code;'?
Good point. IIRC gnulib-tool uses e.g.,
eval 'func_foo () { smart code; }'
That's how m4sh already does it for AS_VAR_APPEND (take a look at
practically any configure script built with recent autoconf):
if (eval as_var=1; as_var+=2; test x\$as_var = x12) 2/dev/null; then :
eval 'as_fn_append ()
{
eval $1+=\$2
}'
else
as_fn_append ()
{
eval $1=\$$1\$2
}
fi # as_fn_append
which works just fine with retarded Solaris /bin/sh.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
No, ${parameter:offset} and ${parameter:offset:length} are bash specific
not XSI mandated.
But we don't need bash-specific hacks.
${parameter#??} serves as a great XSI alternative to ${parameter:2},
and with a (lot) more thought, ${1:1:1} can be written without forks
and without bash-isms as:
tmp=${1#?}
patt=
i=2
while test $i -lt ${#1}; do
patt=?$patt
i=$((i+1))
done
result=${tmp%$patt}
Obviously, you'd want to pick better variable names due to namespace
considerations...
--
View this message in context:
http://old.nabble.com/-PATCH--Add-an-XSI-replacement-for-func_split_short_opt.-tp29005049p29008555.html
Sent from the Gnu - Libtool - Patches mailing list archive at Nabble.com.
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/28/2010 04:19 PM, Ralf Wildenhues wrote:
Hi Eric,
thanks for the suggestion. I had considered the idea for a second, but
failed to see the nontrivial half.
* Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
tmp=${1#?}
patt=
i=2
while test $i -lt ${#1}; do
patt=?$patt
If the parameter may be expected to be very long (which I don't think it
will be) then
func_append patt '?'
would be useful here, and even if not, appending rather than prepending
here helps with current bash.
i=$((i+1))
done
result=${tmp%$patt}
After thinking a bit more, this alternative should do the same job in
fewer lines of code and fewer temporary variables:
result=${1#?}
while test ${#result} -gt 1; do
result=${result%?}
done
Also, you have to be a bit careful:
$ tmp=a
$ echo ${tmp:2}
$ echo ${tmp#??}
a
that is, before trying to split off the first two bytes using XSI, you
must ensure that ${#1} has at least two bytes to be split in the first
place.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Compiler warning in libltdl/m4/libtool.m4 test program
On 06/16/2010 01:48 AM, Philip Allison wrote: On Tue, 2010-06-15 at 20:14 +0200, Ralf Wildenhues wrote: Please note that in general, it is impossible for configure tests to be -Werror clean. That is not only due to the sheer amount of possible erros from different GCC compiler versions (not to speak of others), different sets of warning flags, and system-specific issues, but also because inherently, some configure tests have to do things that are only half-decent C. Thus we strongly recommend to add -Werror only at 'make' run time and not at configure time already. Hmm... not what I had imagined, but point taken. This was the only failure of this kind in the particular configure script I was looking at, but I shall bear this in mind if I run into anything similar in future. Is there a trivial way to specify cumulative flags at make-time, as opposed to an override? Not that the latter is a major issue for me, just means I may have to change a few habits. :) Coreutils serves as an example of a project that probes whether the compiler supports -Werror, then adds a specific Makefile substitution to append -Werror (or the empty string) to the various CFLAGS throughout the project. You can check out coreutils' ./configure --enable-gcc-warnings option. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Enable colored Autotest testsuite output if available.
On 06/13/2010 05:17 AM, Ralf Wildenhues wrote: OK to commit this patch if this one is accepted into Autoconf? http://lists.gnu.org/archive/html/autoconf-patches/2010-06/msg00031.html The move the testsuite.at code above AT_INIT should have no impact beside reordering things in the PREPARE_TESTS diversion a bit, which should be harmless (I checked the diff with current git Autoconf). Thanks, Ralf Enable colored Autotest testsuite output if available. Looks nice to me; in fact, it's probably okay to commit even without autoconf's colored output patch committed yet. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: MSVC: Find potential libs regardless of case.
On 06/14/2010 03:01 PM, Ralf Wildenhues wrote: +eval `$EGREP '^(old_library)=' $libdir/libbar.la` This is probably lacking double-quoting around the `...` text. Can you verify? For that matter, it's not safe in the presence of signals, since some shells end up doing eval '' if the `` is interrupted. You want: str=`$EGREP '^(old_library)=' $libdir/libbar.la` eval $str or possibly even $libdir in the first line to be robust to spaces in file names. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Avoid autom4te warning about unnamed diversion.
On 06/07/2010 02:47 PM, Ralf Wildenhues wrote: I get this warning from recent Autoconf when bootstrapping Libtool: $ ./bootstrap [...] autom4te --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh libltdl/config/ltmain.in libltdl/config/getopt.m4sh:1: warning: prefer named diversions The patch below fixes it. OK? Thanks, Ralf Avoid autom4te warning about unnamed diversion. * libltdl/config/getopt.m4sh: Use diversion name KILL not -1. Yes, that makes sense to me, especially given since I was the one that patched autoconf to intentionally issue that warning. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
[adding autoconf] On 06/06/2010 06:13 AM, Gary V. Vaughan wrote: I see the point in the factorization of the option parsing, and I have to admit to not having tested or even looked in detail at these changes yet, but on a general note, shouldn't we either just use gnulib's announce-gen if it is good enough for us? And if it isn't, shouldn't we try to get the improvements of your version into gnulib's, or even try to get gnulib to adopt the libtool variant? In general, I agree. But personally, I despise perl, and even had I invested the effort in figuring out the correct string of punctuation to make gnulib's version of announce-gen work for our release process... I probably wouldn't have been able to read that code a week later. Anyway, perl rants aside, I think that alongside Autoconf's m4sh.m4sh might make a better home for getopt.m4sh? Yes, I think (given the current contents of m4sh.m4 in autoconf) that the intent has been there for several years to add generic m4sh support for option parsing; but it is undocumented, and woefully undertested. I'm all for improving it - m4sh is indeed the right place to provide an option parsing library. But it will have to wait until after autoconf 2.66 is released. I'm not against the idea of replacing perl code in gnulib with m4sh code either, though I think it might be a hard sell considering that our announce-gen requires a bootstrap time compilation step to turn announce-gen.m4sh into announce-gen the runnable shell script. On the gnulib side of things, a pre-compiled runnable shell script can be checked in, along with a make rule to regenerate that script from the .m4sh sources. Jim may be on the opposite side of the fence from you (he prefers perl over portable shell), but it would certainly be worth raising the issue on the gnulib list, once autoconf has better m4sh support for option parsing. Or perhaps both scripts can live in gnulib, perl and m4sh versions, side-by-side. The beauty of gnulib is that it provides a nice source for pieces you care about, even if you don't use every piece available. So it does seem like a better (eventual) home for these recent libtool m4sh scripts. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 03/17/2010 01:23 PM, Dave Korn wrote:
On 17/03/2010 17:14, Eric Blake wrote:
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
Thanks, that's a new one to me. OTOH, the texinfo documentation for @sc
suggests that GNU is an acronym, and so I would think is DOS, so maybe that
tag should be used instead of sc.
Not to mention the current debate on the automake list on whether GNU or
@acronym{GNU} is preferred in GNU manuals (Karl Berry is arguing that it
is simpler to blindly write GNU, rather than either @acronym{GNU} or
@sc{gnu}, and that the differences in font rendering in dvi/pdf files
aren't worth worrying about by just going with the solution with the
least typing).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [patch] sort 'find' output to enable deterministic builds.
On 03/15/2010 01:12 PM, Chris Demetriou wrote: The attached patch sorts the output of 'find' in all cases (where it's not already sorted), so as to produce deterministic results. Does libtool globally force the C locale, or do you need to use: LC_ALL=C sort throughout your patch to further ensure deterministic behavior across different default locales? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Happy New Year
According to Ralf Wildenhues on 1/6/2010 12:08 AM: Pushed to master. Cheers, Ralf Bump copyright years. GNU Coding Standards permit bumping the copyright on all files in the project, not just those that have had significant edits in the current year. If you are interested, we can run build-aux/update-copyright from gnulib in order to achieve that action (it also has the benefit of normalizing copyrights into a consistent format). -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature
Re: Remove meaningless conditional op from lt_dlerror.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 12/29/2009 7:25 PM: Hi! I'm about to push this too as obvious, I hope I'm not getting too bold... It looks obvious enough; go ahead. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6y5oACgkQ84KuGfSFAYBgrwCgtken/zYaUpx55t9h6YU0JZc9 qfUAnjYQCU4Va59vbca9eQIozt1YFypB =Vg8g -END PGP SIGNATURE-
avoid compiler warning
I'm seeing this when compiling with -Wall: | libltdl/ltdl.c: In function ‘try_dlopen’: | libltdl/ltdl.c:1267: error: the address of ‘libext’ will always evaluate as ‘true’ The problem is that LT_STRLEN is checking for null pointers, but the address of an array can never be null. But using a const * instead of an array silences the warning. OK to commit this? From: Eric Blake e...@byu.net Date: Mon, 2 Nov 2009 11:58:28 -0700 Subject: [PATCH] Allow gcc builds with -Wall -Werror. * libltdl/ltdl.c (libext): Declare as pointer rather than array to silence gcc warning. Signed-off-by: Eric Blake e...@byu.net --- ChangeLog |6 ++ libltdl/ltdl.c |4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index caf125a..ab0a39f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-11-02 Eric Blake e...@byu.net + + Allow gcc builds with -Wall -Werror. + * libltdl/ltdl.c (libext): Declare as pointer rather than array to + silence gcc warning. + 2009-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de Fix func_normal_abspath sed script for Solaris. diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c index 80b5675..4c57496 100644 --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -1,7 +1,7 @@ /* ltdl.c -- system independent dlopen wrapper Copyright (C) 1998, 1999, 2000, 2004, 2005, 2006, -2007, 2008 Free Software Foundation, Inc. +2007, 2008, 2009 Free Software Foundation, Inc. Written by Thomas Tanner, 1998 NOTE: The canonical source of this file is maintained with the @@ -71,7 +71,7 @@ or obtained by writing to the Free Software Foundation, Inc., static const char objdir[]= LT_OBJDIR; static const char archive_ext[] = LT_ARCHIVE_EXT; -static const char libext[]= LT_LIBEXT; +static const char * const libext = LT_LIBEXT; #if defined(LT_MODULE_EXT) static const char shlib_ext[] = LT_MODULE_EXT; #endif -- 1.6.4.2
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dave Korn on 8/14/2009 5:34 AM: Still finishing it off and getting it tested, but while that's going, here's a preview of the path canonicalisation function as I've got it so far; let me know if I've done any major no-nos please! pathcar=s,^/\([^/]*\).*$,\1, pathcdr=s,^/[^/]*,, removedotparts=s,/\(\.\(/\|$\)\)\+,/,g collapseslashes=s,/\+,/,g # func_normal_abspath path # Remove doubled-up and trailing slashes, . path components, # and cancel out any .. path components in PATH. Cancelling out .. is wrong for 'symlink/..', when symlink does not necessarily point to a working directory exactly one level down. (True, cygwin does not implement POSIX semantics here, and cancels out foo/.. behind your back rather than properly resolving foo, but this function will need to work on all other systems that do it correctly). func_normal_abspath_tpath=$1 Double-quoting not necessary here - variable assignment is already in a quoted context, and quotes are only needed to protect metacharacters. case $func_normal_abspath_tpath in Likewise - the case argument is already in a double-quoted context. ) # Empty path, that just means $cwd. func_stripname '' '/' `pwd` Can we rely on $PWD instead of forking a process? func_normal_abspath_result=$func_stripname_result return ;; /*) # Absolute path, do nothing. Do we want to cater to DOS style absolute paths? [a-z]:\\ ;; *) # Relative path, prepend $cwd. func_normal_abspath_tpath=`pwd`/$func_normal_abspath_tpath Again, double quotes aren't necessary. ;; esac # Cancel out all the simple stuff to save iterations. func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \ -e $removedotparts -e $collapseslashes` I thought we were trying to move away from $ECHO and instead use the shell functions. And you have a portability no-no, documented in the autoconf manual: a=`` is non-portable, but can always be replaced by the portable: a=`` See why I don't like spurious around variable assignments? # We want the path to end with a slash for ease of parsing, and # doubled-up slashes won't hurt us here, so just add one on. func_normal_abspath_tpath=$func_normal_abspath_tpath/ while :; do func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | $SED \ -e $pathcar` func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \ -e $pathcdr` Nit - I'd break these long lines at |, not after $SED, so that the entire sed command is on a single line. # Figure out what to do with it case $func_normal_abspath_tcomponent in ) # Trailing empty path component, ignore it. ;; ..) # Parent dir; strip last assembled component from result. func_dirname $func_normal_abspath_result func_normal_abspath_result=$func_dirname_result ;; *) # Actual path component, append it. func_normal_abspath_result=$func_normal_abspath_result/$func_normal_abspath_tcomponent ;; esac # Processed it all yet? if test $func_normal_abspath_tpath = / ; then # If we ascended to the root using .. the result may be empty now. if test -z $func_normal_abspath_result ; then func_normal_abspath_result=/ fi break fi done } - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqFV58ACgkQ84KuGfSFAYAGLwCeNF5H7L+noHCwyR6MDPwuFnTk zJIAoMC0kyZtLZHd9bx4PX4m/J6pcF/O =y3KX -END PGP SIGNATURE-
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dave Korn on 8/14/2009 7:11 AM: a=`` is non-portable, but can always be replaced by the portable: a=`` See why I don't like spurious around variable assignments? Ah, now I do. Ok, but is some nice clear list of where you should and shouldn't quote anywhere? As far as I can tell you have to memorize the entire bash manual and then infer what to do from all the overlapping sets of expansions and contexts and rules. Then you have to to the same for all the other shells we're supposed to support. Then you have to infer a set of lowest-common-denominator rules from all of that. I think it's as simple as: if you are doing variable assignment, there is no word splitting, so you only need quotes if it would otherwise look like multiple words: a=$1 b=$1 $2 if you are doing case statements, there is no word splitting, so you only need quotes if it would otherwise look like multiple words: case $1 in case $1 in if you are doing `` which needs embedded quoting, then it is only safe to do it as variable assignment (where `` looks like a single word, without needing outer ): a=`echo $1 $2` pretty much every where else, all $ expansions need double quotes if you want to avoid word splitting (but using $ expansions to hide tool names is one case where you DO want word splitting): ECHO='printf %s\n' $ECHO $1 And beyond that, it's just lots of practice. I agree that it often feels like you have to memorize loads of information to write portable shell, but at least these public reviews catch a lot of the pitfalls. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqFYVAACgkQ84KuGfSFAYBIRwCgxRt0p2lnFnSfQOHl0TR1puou rPoAoJsTLkaB4QMg6ZcTsD2bKqNWftfQ =wagC -END PGP SIGNATURE-
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Charles Wilson on 6/30/2009 6:05 AM: The attached patch was submitted on the cygwin list by Yaakov Selkowitz, and is currently included in the cygwin libtool distribution. It has received some objection (notably by Peter Rosin) over there, but I'll let him speak for himself -- I'm posting this version explicitly to attract comments so the patch can be refined. Do we need to worry about deleting *.manifest files at the appropriate 'make *clean' level? + # Create the UAC manifests first if necessary + case $output_name in + *instal*|*patch*|*setup*|*update*) + func_emit_exe_manifest $cwrapper.manifest + func_emit_exe_manifest $output_path/$objdir/$output_name.exe.manifest Would it be more efficient to use tee or cp, rather than two calls to func_emit_exe_manifest? Does the .manifest need +x permissions? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpKB6oACgkQ84KuGfSFAYC+VgCfV2wYdwWoAfFG6FwW3bWoHX8w YJ8AoKOdTq0oK/17Esf373iu0XSme87/ =vYc5 -END PGP SIGNATURE-
Re: Strange LT_INIT behavior
Peter O'Gorman peter at pogma.com writes: As far as I can tell, the AC_REQUIRE is unnecessary, in the case where AC_PROG_F77 comes before LT_INIT, the compiler has already been tested before we get to _LT_LANG_F77_CONFIG (this is guaranteed by the AC_PROVIDE_IFLESE) in the other case, the compiler check is also guaranteed because we have redefined AC_PROG_F77 so that it has both the compiler check and _LT_LANG_F77_CONFIG. Your analysis seems correct to me - thanks for tracking it down. In other words, by making libtool never directly expand AC_PROG_F77, while still guaranteeing that the libtool hook of _LT_LANG_F77_CONFIG will always occur after the user's use of AC_PROG_F77, libtool no longer gets in the way of arguments supplied by the user. Also, I have no idea what to do when removing macros from libtool.m4, do I need to do something with lt~obsolete.m4? I think that only matters for publicly exported macros; since you are deleting _LT_PROG_F77 from the libtool internal namespace, no one outside of libtool should have been calling it, so there is probably nothing else to worry about. All that said, I am not the biggest libtool contributor, so if you want to wait 72 hours for anyone else to also chime in with a review, that would be fine with me. If the three days pass without further comment, then consider my review as sufficient. -- Eric Blake
Re: compiler version checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/27/2009 2:05 PM: Thanks. This finally gave me enough incentive to do something about this long-standing issue. OK to push this Autoconf patch and add Christian and John to THANKS? In general, I'm happy with the idea. But let's answer this question first: +# Limit stderr logging to avoid copying full manpages. +_AC_DO_LIMIT([$ac_compiler --version AS_MESSAGE_LOG_FD]) +_AC_DO_LIMIT([$ac_compiler -v AS_MESSAGE_LOG_FD]) +_AC_DO_LIMIT([$ac_compiler -V AS_MESSAGE_LOG_FD]) +_AC_DO_LIMIT([$ac_compiler -qversion AS_MESSAGE_LOG_FD]) Rather than have four consecutive copies of _AC_DO_LIMIT, wouldn't something more compact like this (untested) snippet work? for ac_option in --version -v -V -qversion ; do _AC_DO_LIMIT([$ac_compiler $ac_option AS_MESSAGE_LOG_FD]) done - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn2SeIACgkQ84KuGfSFAYCAyQCgnDVW0pbM0CHE4G8WY+ohJPur wK8AnjnFoiNvybmfljwD2ZBs6UWh1INg =PYyK -END PGP SIGNATURE-
Re: Rebase of the pr-msvc-support branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 1/9/2009 3:11 AM: Den 2009-01-09 03:58 skrev Eric Blake: Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal I don't have gnulib-tool, which is mentioned in that file, how do I get hold of that tool (for cygwin)? Here's how to get a shallow gnulib clone, then build git-merge-changelog: $ git clone --depth=1 git://git.sv.gnu.org/gnulib.git $ gnulib/gnulib-tool --create-testdir --dir=/tmp/testdir123 \ git-merge-changelog $ cd /tmp/testdir123 $ ./configure $ make $ make install (optionally you can check out all of gnulib, by removing --depth) you also have to modify .git/config (or ~/.gitconfig) to install git-merge-changelog as your merge handler for changelogs. Hmm, is it allowed for ChangeLog entries to not be in chronological order? Or should I redate them when I rebase? That point is a bit fuzzy; personally, I'm okay with preserving the date that a patch was written, but ordering the changelog in the order patches were applied (so dates are out of order), but rewriting the entries to have the date of the merge is also probably acceptable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklnT7UACgkQ84KuGfSFAYCSigCeNKGQkS0swWILxvaxBkxi8ncD MnQAoLvZpKHnwFCeTtjjPDWFMtkHiEuD =+iQk -END PGP SIGNATURE-
Re: Rebase of the pr-msvc-support branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 1/8/2009 12:43 PM: Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Should I create a new topic branch named pr-msvc-support2? Should I merge git-head into the branch? That sure feels backwards, but what do I know? Please help. Now that you've told us the branch will be rebased, it makes sense to just keep the same branch name, rebase locally, then push that rebased branch in place of the current one. Rebasing topic branches is acceptable with advance warning, and as long as we don't rebase the master branch. One final minor question, should we skip the patches to ChangeLog in the branch and recreate that part of the patches when/if the branch is merged? It seems that there is approximately 100% risk for the ChangeLog hunk to cause merge problems. Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal hassle, reducing the risk of a ChangeLog merge interfering with your rebase from 100% down to about 2%. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmvVwACgkQ84KuGfSFAYBDnACeNFJnSH1GEGIwAWt0h1JfXfMJ vY8AniR9sshdBEkqEvCupRchs18Kf38J =jvW4 -END PGP SIGNATURE-
Re: Fix ltmain.sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Akim Demaille on 12/19/2008 3:47 AM:
I'm a contributor to GNU Libtool, and proud of it!
Indeed, with copyright assignment since 2001!
Please find attached
a patch fixing a critical bug.
Can you convince your mailer to send patches with a text MIME type,
instead of application/octet-stream? It makes reviewing a lot easier when
patches can be read inline, instead of having to save them off to another
file.
Don't forget to credit me in THANKS ;)
You are already there ;)
At any rate, this patch looks sensible, except that while we are adjusting
the line, we might as well wrap to fit in 80 columns. And we need a
ChangeLog entry. I'm pushing this:
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklLnT0ACgkQ84KuGfSFAYAo/QCgiW1fexO8gShA7IRA3ANH+f18
rhoAniE5mBflzJdrx6y+lzJJOK3Zndfh
=FeoZ
-END PGP SIGNATURE-
From 756f95dd608704d2327929412a9a023ca822a079 Mon Sep 17 00:00:00 2001
From: Akim Demaille demai...@gostai.com
Date: Fri, 19 Dec 2008 11:45:05 +0100
Subject: [PATCH] Fix copyright notice.
* libltdl/config/ltmain.m4sh: Add missing comma.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog |5 +
libltdl/config/ltmain.m4sh |5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ce3b324..65eef10 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-12-19 Akim Demaille demai...@gostai.com
+
+ Fix copyright notice.
+* libltdl/config/ltmain.m4sh: Add missing comma.
+
2008-12-17 Ralf Wildenhues ralf.wildenh...@gmx.de
Add cache variables to link tests.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 2769149..20ca07b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4,7 +4,8 @@ m4_divert_push([SCRIPT])# @configure_input@
# libtool (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
# Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006,
2007 2008 Free Software Foundation, Inc.
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
+# 2006, 2007, 2008 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@@ -455,7 +456,7 @@ $opt_help || {
# determined imposters.
func_lalib_p ()
{
-test -f $1
+test -f $1
$SED -e 4q $1 2/dev/null \
| $GREP ^# Generated by .*$PACKAGE /dev/null 21
}
--
1.6.0.4
Re: Avoid accidental disastrous space cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Akim Demaille on 12/19/2008 5:08 AM: I have been bitten by this :( So has autoconf, which is why all m4sugar scripts currently start with the shorter: IFS= $as_nl Which makes me wonder - do we even need this patch, or is it sufficient to entirely delete libtool's IFS initialization in favor of m4sugar's, thanks to Paolo's recent cleanups to use m4sugar as documented? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklLoSEACgkQ84KuGfSFAYBFpACeMe4+YwoXImZuDLLtsyMkxkyy xGoAoK0rT/yqomsxLpKkqYFMtZEy7WMS =hGph -END PGP SIGNATURE-
Re: Fix ltmain.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 12/19/2008 6:45 AM: Den 2008-12-19 14:10 skrev Eric Blake: *snipped* +Fix copyright notice. +* libltdl/config/ltmain.m4sh: Add missing comma. Oooaa, excellent (and while we are all nitpicking), a whitespace cleanup patch that adds whitespace mistakes (should be a tab before the asterisk)... Blah. So much for me copying and pasting from the terminal's 'git log' display into my editor. Now fixed. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklLpqMACgkQ84KuGfSFAYASzACbBJCIeOvZEfqoe0YJxrfT3CV5 NHMAnj2UHr5/qkzUGp6GXHlC3M3EGJ7H =svbX -END PGP SIGNATURE-
Re: [PATCH 6/6] use print or printf or cat as $ECHO (really)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 11/23/2008 1:10 AM:
At least we can hard-code the fact that ZSH_VERSION or
BASH_VERSION implies a builtin printf, to skip the forks on those shells.
You mean like this?
Are we certain enough no bash or zsh version has problems with a long
format string?
I'm not certain they are bug-free on all possible formats (for example,
printf %10s\\n), but for our usage, they do just fine on long strings
where Solaris /bin/printf does not.
+ test -n ${ZSH_VERSION+set}${BASH_VERSION+set} || {
+
ECHO='\\\'
+ECHO=$ECHO$ECHO$ECHO$ECHO$ECHO
+ECHO=$ECHO$ECHO$ECHO$ECHO$ECHO$ECHO
+( PATH=/empty FPATH=/empty; export PATH FPATH
+ test X`printf %s $ECHO` = X$ECHO ) }])])
Still not enough. Solaris /bin/sh correctly fails this test. However,
because we did not check for print, Solaris ksh _also_ fails the test, and
we end up wrongly favoring /bin/sh, even though it lacks a builtin. On
Solaris, we _want_ to choose ksh over /bin/sh, because builtin print is
faster than the here-doc fallback used in /bin/sh. I think the last line
has to be:
( PATH=/empty FPATH=/empty; export PATH FPATH
test X`printf %s $ECHO` = X$ECHO \
|| test X`print -r -- $ECHO` = X$ECHO ) }])])
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkpaCEACgkQ84KuGfSFAYAiKwCcCiuwIlxSv7qI7fhpLNnGB5R5
gzMAn2zjMeQxPs2liMcCc4xJTbQBlU9a
=7sSU
-END PGP SIGNATURE-
Re: [PATCH 6/6] use print or printf or cat as $ECHO (really)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 11/22/2008 6:57 AM: I propose two alternative patches to fix these issues. Both, as the code before the patch, assume that `test' is a built-in command. Yuck. But reasonably safe; per http://www.in-ulm.de/~mascheck/bourne/, all System III shells provide this. + PATH=/empty FPATH=/empty test X`printf %s $ECHO` = X$ECHO])]) Your attempt to modify PATH in-place won't work. Even with bash 3.2: $ foo=bar echo `env | grep foo` $ In other words, although echo sees the altered $foo, the `` subshell does not. + ( PATH=/empty FPATH=/empty; export PATH FPATH +test X`printf %s $ECHO` = X$ECHO )])]) Yes, that looks more portable (even if it is slower). But do we even need to _AS_DETECT_SUGGEST for a working builtin printf? As long as we search for 'print -r' before 'printf', we are either guaranteed to find the working builtin variant, or we end up resorting to forking no matter which alternative we choose. The primary use case where this will help is with Solaris /bin/sh, which lacks both builtins, so we really _do_ want to suggest a shell that is more likely to provide a builtin. But on a Solaris machine, ksh fails the suggested test (it lacks builtin printf), so ksh is not determined to be better than /bin/sh, and you end up running with /bin/sh and forking for every $ECHO anyway. Maybe a better suggested test would be one that checks for either print or printf (that way, a Solaris machine will let ksh pass the suggested test). Since the overall test is running with stderr silenced, we don't even have to worry about messages about command not found. In other words, why not: _AS_DETECT_SUGGESTED([ ECHO='\\\' ECHO=$ECHO$ECHO$ECHO$ECHO$ECHO ECHO=$ECHO$ECHO$ECHO$ECHO$ECHO$ECHO test X`print -r -- $ECHO` = X$ECHO \ || test X`printf %s $ECHO` = X$ECHO]) - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkoF64ACgkQ84KuGfSFAYAGRgCeM3rJDiTmFgdSSOu74dwNqpd+ CmkAnR++b8sDGKRxrWW+ovGcgZqcCJoU =GuTz -END PGP SIGNATURE-
Re: [PATCH 6/6] use print or printf or cat as $ECHO (really)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/22/2008 7:31 AM: Maybe a better suggested test would be one that checks for either print or printf (that way, a Solaris machine will let ksh pass the suggested test). Since the overall test is running with stderr silenced, we don't even have to worry about messages about command not found. In other words, why not: test X`print -r -- $ECHO` = X$ECHO \ || test X`printf %s $ECHO` = X$ECHO Scratch that; Solaris /bin/sh passes that test, so we wouldn't favor ksh. It really boils down to finding a shell with either print or a builtin printf, so I think we have to play the PATH games, and expend the extra fork in looking :( At least we can hard-code the fact that ZSH_VERSION or BASH_VERSION implies a builtin printf, to skip the forks on those shells. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkoGQ8ACgkQ84KuGfSFAYBUUACfSnEOeNxt190rKmNMRWpHbd2x 560AoK3c92s6Czz2tCIyyUH3oQAywo5m =8rWl -END PGP SIGNATURE-
Re: Revenge of the $ECHO. Kill most uses of Xsed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 11/17/2008 12:10 AM: $ECHO run \`$progname --help | more' for full usage This can be echo rather than $ECHO, since the \` is flattened during interpratation prior to the echo call. Several similar places exist. What about $progname? Ah, it should be a basename. Well, our current basename functions don't compute the basename of files with backslash as directory separator. On second thought, how do we compute basename? On platforms like Linux, it is legal to have \ in $0 (and thus $progname) that are not treated as directory separators. So this particular instance must indeed remain $ECHO. - RM=$ECHO $RM + RM=echo $RM Are all of these safe, considering mingw might have \ in an absolute pathname to these tools? No, and I'm glad you ask about this. The point here is that there is more than one argument following, and I didn't see an easy way to escape them properly, so I figured take the less likely of the bugs, as RM=$ECHO rm -f is quite certain to do the wrong thing. Suggestions? Well, on mingw native, the default sh has an echo that doesn't eat \. But that doesn't help if you are doing a Solaris-mingw cross. I'm also stumped on thinking of any better alternative, though. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkjoDsACgkQ84KuGfSFAYA4mQCfd1cF7EWl5zRowXU4UMSKJycZ 4MEAnRFcZC9+Ev86Im9cNzGK0AvYXtVr =59w4 -END PGP SIGNATURE-
Re: help2man missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Friesenhahn on 11/12/2008 10:33 AM: So then I tried installing help2man 1.36.4 and its configure script fails with: checking for pre-loadable libintl... no configure: error: libpreloadable_libintl.so required (gettext 0.12+) Try './configure --disable-nls', and see if that helps. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbHcAACgkQ84KuGfSFAYBBPACfX1qtKuuhUHLmIj5/2NU6nfs2 XCAAnisEmJLvcOYey8vMkd/LjbJE1PCV =qm3K -END PGP SIGNATURE-
Re: [PATCH 6/6] use print or printf or cat as $ECHO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 11/10/2008 5:06 AM: 1) I don't have access to systems that are old or weird enough to check if the performance penalty will happen often. What do you think? A single-fork fallback is better than nothing, and better than any expr or other multi-fork fallback. But preferring a builtin is definitely the way to go. 2) If ksh had a way to print without interpreting escapes *and dashes*, I'd be glad to add it; do you know one? I thought of one after lunch: print -r -- FOO. This way we can print without forking on bash, zsh, ksh, ash/dash. 'man print' on Solaris 10 shows that ksh also understands print -R - as a way to print - (but not -n or --). But you are right in realizing that print -r -- seems to work nicely. At any rate, that means we should probably teach m4sh to try print -r -- as one of its options, prior to printf %s\\n, during _AS_ECHO_PREPARE. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYOQcACgkQ84KuGfSFAYAOOwCdEpPvxch0jfDi1Mv2Okalm/vI KbIAn2407Ron5tQfg3rGAlIUqYKoeoSQ =K5/F -END PGP SIGNATURE-
Re: [PATCH 6/6] use printf as $ECHO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 11/10/2008 4:07 AM: Just for safety, shouldn't the test use '%s\n' rather than bare %s (in other words, make our test match our usage pattern)? _AS_ECHO_PREPARE does the same... Here's a chance to fix both at once. :-) To be more precise, Autoconf also needs an echo -n emulation, so it does use printf %s too. I just copied the assumption that if one works, the other does too. After more thought, I'm okay with that assumption. printf(1) is a new enough invention that all known implementations, even non-builtins, manage \n format sequence correctly. 1) portability. I looked again at Sven Mascheck's pages, and you're probably thinking of http://www.in-ulm.de/~mascheck/various/uuoc/ where he says: Here documents [used with cat] force `as-is' output, if there are character sequences which are special to echo(1), and if printf(1) is not available. Equally as expensive as when printf exists but not as a builtin. Can't implement AS_ECHO_N, but that is not a problem for libtool's usage. So I like the idea of using cat as the fallback, rather than 'printf of another shell'. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYPSQACgkQ84KuGfSFAYChhQCgh8qvESxZuPyucESvvk1HFbLj AIYAoM1+jhGhmKXE5fUZosMAfJNa6lzg =0zkc -END PGP SIGNATURE-
Re: [PATCH 1/6] Avoid that autom4te complains about unexpanded macros
Paolo Bonzini bonzini at gnu.org writes: In the meanwhile, the series cleans up some problematic usages of M4sh, so the preliminary patches can be applied independently. A disclaimer - while I am a maintainer of autoconf (and hence m4sh), I am only a contributor on libtool, and not the most prolific at that, so my reviews don't hold quite as much weight on this list as on autoconf-patches. That said, I still think I'm qualified to chime in with concurrence, whether or not you wait for an additional reviewer. +++ b/libtoolize.m4sh @@ -1,5 +1,7 @@ +m4_pattern_allow([dnl]) Forbidding dnl is a safety valve in m4sugar; by allowing it, you are no longer able to catch typos in future edits that accidentally overquote and leave raw dnl in the final output file. On the other hand, I think libtoolize.m4sh is small enough to carefully audit (it is not like configure.ac, where catching errors in third-party macros is nice, since libtoolize doesn't really depend on third-party code). And since libtoolize's job is to scan configure.ac (including ignoring dnl in configure.ac), there is a strong argument for having literal dnl in the output without having to add quadrigraphs everywhere. So I'm okay with this patch as-is. That said, it would be nicer if libtoolize could use autom4te --trace rather than sed scripts to learn some of what it scans from configure.ac, but that's unrelated to this patch series... -- Eric Blake
Re: [PATCH 2/6] run sh.test on the m4sh source
Paolo Bonzini bonzini at gnu.org writes: This is also an independent cleanup. It is useless to play against M4sh's usage of shell syntax. We can trust M4sh to know what is doing. So, sh.test might as well be run against the pre-m4 sources. * tests/defs.m4sh (scripts): Point to pre-m4 sources. Looks sane to me (and it gives M4sh a bit more freedom; we've already had patches in the past month where we intentionally added bulk to M4sh to work around libtool's sh.test, and I would like to break that reverse dependency). -- Eric Blake
Re: [PATCH 3/6] use documented m4sh interfaces
Paolo Bonzini bonzini at gnu.org writes:
Here we start with the meat. This patch ends Libtool's indiscriminate
usage of undocumented (and in some cases deprecated) M4sh interfaces.
AS_SHELL_SANITIZE is replaced with either AS_INIT or AS_INIT_GENERATED
(the latter also subsumes _AS_PREPARE), and the standard M4sh diversions
are used. AS_INIT_GENERATED is a new macro in Autoconf's latest git,
whose source we include in libtool.m4 if needed. (Actually we copy it
to _LT_INIT_GENERATED, with some hacks, to avoid problems with aclocal
pull libtool.m4 into every file).
I know you mentioned (in 7/6) that you can turn on enough porting hacks to
allow running with Autoconf 2.60; does that include this patch?
PROGRAM=clcommit
-AS_SHELL_SANITIZE
-$as_unset CDPATH
-
+m4_divert_pop
When possible, it's nicer to use the 1-argument m4_divert_pop, as a sanity
check that no macro changed the active diversion (with m4_divert or otherwise)
in the meantime. For this instance, this should be:
m4_divert_pop([HEADER-COPYRIGHT])
+++ b/libltdl/m4/libtool.m4
@@ -553,6 +553,34 @@ esac
_LT_OUTPUT_LIBTOOL_INIT
])
+# AS_INIT_GENERATED(FILE, [COMMENT])
s/AS/_LT/
I still have some pending ideas for AS_INIT_GENERATED (such as bumping the
value of _m4_divert(BODY) and adding an m4_wrap hook that can then minimize the
preface of generated files to m4sh features actually used, rather than dumping
all of _AS_PREPARE in every child script); I guess we have to decide if your
current fallback implementation of _LT_INIT_GENERATED it is mature enough to
use even if AS_INIT_GENERATED changes in the future, or whether you plan to
track future upstream changes. Or put another way, by using this interface,
you are now locking down the API that we must publish for AS_INIT_GENERATED in
the next autoconf release; so hopefully we are happy that it is a sufficient
interface (and that all future tweaks on the m4sh side of things will only be
optimizations, rather than interface changes). At any rate, since 2.64 (or
should it be autoconf 3.0?) isn't released yet, would it be worth adding a
comment mentioning which commit you borrowed the fallback from?
+[m4_defun([_LT_INIT_GENERATED],
+[m4_require([AS_PREPARE])]dnl
+[m4_pushdef([AS_MESSAGE_LOG_FD])]dnl
+[as_write_fail=0
I guess we are safe invading the m4sh namespace in our fallback, if only
because we know that all supported versions of autoconf that lack
AS_INIT_GENERATED did not use as_write_fail.
+_LT_INIT_GENERATED([$CONFIG_LT],
+[# Run this file to recreate a libtool stub with the current configuration.])
I knew I made the right decision by adding that optional comment argument. ;)
+AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
...
-AS_SHELL_SANITIZE
-$as_unset CDPATH
I just checked that as far back as autoconf 2.59, AS_INIT was still doing
AS_SHELL_SANITIZE. For now, 2.59 is the current PREREQ in configure.ac,
although libtool.m4 claims it can get by with 2.58. However, AS_SHELL_SANITIZE
didn't unset CDPATH until 2.60; that argues that we should either add a
AC_PREREQ([2.60]) (for just configure.ac while bootstrapping libtool? or for
libtool.m4?), or else provide a fallback and continue to unset CDPATH manually
(perhaps after doing an m4_version_compare; gcc has a good example of a
portability package for a number of newer autoconf features ported to an older
autoconf environment).
+++ b/tests/testsuite.at
@@ -23,6 +23,8 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+AT_INIT
+
m4_divert_push([PREPARE_TESTS])dnl
: ${tst_dist=dist}
: ${ACLOCAL=aclocal}
@@ -369,5 +371,4 @@ dnl AT_TESTED([grep autoreconf autom4te automake])
## The suite. ##
## --- ##
-AT_INIT
-# The other tests will be appended here by the Makefile rule.
+# Tests will be appended here by the Makefile rule.
This move seems a bit unrelated to the others and a bit more cosmetic in
nature, but I guess it's okay as part of this patch.
--
Eric Blake
Re: [PATCH 6/6] use printf as $ECHO
Paolo Bonzini bonzini at gnu.org writes:
This patch bumps the requirement for *building* Libtool to
Autoconf 2.62, which provides a handy $as_echo which does
exactly the same as we need for Libtool. However, Libtool
itself uses its own echo replacement, so it is not tied to
Autoconf 2.62.
Should we relax to 2.61a instead (as that is still available on alpha.gnu.org,
and was the first release to actually have $as_echo)? Not that it matters
much, the set of people who bootstrap libtool is much smaller than the set of
people who use libtool in building another package (and as most of them are on
this list, and are probably already using autoconf 2.63 or even newer on at
least a part-time basis...)
* configure.ac: Bump Autoconf requirement.
* libltdl/config/general.m4: Use $as_echo as default $ECHO.
* tests/testsuite.at: Use $as_echo as default $ECHO.
* libltdl/m4/libtool.m4 (LT_INIT): Add _LT_SHELL_INIT to
work around Autoconf 2.64 bug.
(_LT_OUTPUT_LIBTOOL_COMMANDS_INIT): Create func_do_echo if
needed. Eliminate lt_ECHO requoting.
(_LT_SHELL_INIT): Use a public M4sh diversion.
(_LT_PROG_PRINTF_BACKSLASH): New.
(_LT_PROG_ECHO_BACKSLASH): Rewrite.
(LT_CMD_MAX_LEN): Do not use --fallback-echo.
* libltdl/config/ltmain.m4sh: Create func_do_echo. Remove
fallback echo handling.
(func_emit_wrapper_part1): Quote lt_cmd_ECHO, lt_func_ECHO,
ECHO. Remove fallback echo handling.
(Execute mode): Do not set qecho.
-AC_PREREQ(2.59)dnl We use AS_HELP_STRING
+AC_PREREQ(2.62)dnl Some m4sh scripts use $as_echo
dnl Oldest automake required for bootstrap is below in AM_INIT_AUTOMAKE.
Should we enhance this comment to mention that the configure.ac for
bootstrapping libtool is more stringent than the requirement for using libtool,
just so casual readers aren't scared by this line?
M4SH_VERBATIM([[
Hmm. This is a nicer name for m4_echo, for how it is being used; maybe it is
time to migrated it into the Autoconf manual (perhaps under the name
AS_VERBATIM)?
: ${CP=cp -f}
-: ${ECHO=echo}
+: ${ECHO=$as_echo}
This is delving a bit into m4sh internals ($as_echo is undocumented, only
AS_ECHO is public), but it seems a lot less painful to maintain than what this
patch is replacing. Maybe it's time to create/document AS_ECHO_PREPARE as the
kosher way to get $as_echo?
+
+AC_MSG_CHECKING([for a working printf])
This looks a bit confusing in configure output; would it be better to
state printf(1) rather than printf (since many people think of printf(3)
first)?
+if test X`printf %s $ECHO` = X$ECHO; then
+ ECHO='printf %s\n'
Just for safety, shouldn't the test use '%s\n' rather than bare %s (in other
words, make our test match our usage pattern)?
+ as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+ for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
What a lot of duplicate code, all because _AS_PATH_WALK is undocumented. Oh
well; you did the right thing by not using an undocumented interface, even if
it is bulky.
+for as_base in sh bash ksh zsh sh5; do
+ as_shell=$as_dir/$as_base
+ test -f $as_shell || test -f $as_shell.exe || continue
On the other hand, your copy-n-paste means that you are using a lot of m4sh
variables; it would be a bit nicer to see these in the lt_ namespace rather
than as_.
+ lt_func_ECHO='func_do_echo () { '$as_shell' -c $lt_cmd_ECHO x $[]
1;}'
This fallback forks for every echo. Can't we rely on $as_echo (if it is
builtin) rather than having to find an external program?
+case $ECHO in
+ printf*) AC_MSG_RESULT([shell builtin]) ;;
+ */printf*) AC_MSG_RESULT([$as_dir/printf]) ;;
I guess we aren't worried about mingw \ directory separators? On the other
hand, any shell ported to mingw tends to have working print.
I may have missed something, but it seems like this patch now requires that the
$ECHO solution be based on 'printf', even if a shell has a builtin 'echo' that
fills the job. Is it worth still checking whether 'echo' fits the bill, in
case it can avoid the forks of lt_func_ECHO?
--
Eric Blake
