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: [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 2>&1; 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: 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: 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: 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: [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 2>&1 || (exit 77)]) > +fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool > >/dev/null 2>&1 || exit 77 > -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix syntax for cygwin-cross
[adding bug-gnulib] On 08/22/2010 11:34 PM, Ralf Wildenhues wrote: Hi Charles, * Charles Wilson wrote on Mon, Aug 23, 2010 at 07:18:18AM CEST: libltdl/m4/argz.m4: Add quotes around variable, which may contain the multiword value 'guessing no'. OK, thanks! This should probably also go upstream to gnulib. Yes, will sync there later. Sync'd to gnulib now. -- 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): cat< 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
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): cat< 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 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. Vaughan * 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
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: 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. cat>file< 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. cat>file< 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. cat>file< 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 --- 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 + + maint: ship .xz, not .lzma + * configure.ac (AM_INIT_AUTOMAKE): Prefer better file format. + 2010-09-13 Ralf Wildenhues 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
[PATCH] maint: ship .xz, not .lzma
* 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. * .gitignore: Ignore .xz files. Signed-off-by: Eric Blake --- > > I'm fine with, if you also adjust HACKING, .gitignore, Makefile.maint. > No objections. This is what I'm pushing. .gitignore |1 + ChangeLog |9 + Makefile.maint | 18 +- configure.ac |2 +- 4 files changed, 20 insertions(+), 10 deletions(-) diff --git a/.gitignore b/.gitignore index bc71270..17050be 100644 --- a/.gitignore +++ b/.gitignore @@ -43,6 +43,7 @@ libtool libtool-*.tar.bz2 libtool-*.tar.gz libtool-*.tar.lzma +libtool-*.tar.xz libtoolize libtoolize.in manual.html diff --git a/ChangeLog b/ChangeLog index 39c3e7a..543623f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2010-09-14 Eric Blake + + maint: ship .xz, not .lzma + * 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. + * .gitignore: Ignore .xz files. + 2010-09-13 Ralf Wildenhues doc: avoid long lines in input and output, indexing fixes. diff --git a/Makefile.maint b/Makefile.maint index 784b155..e176713 100644 --- a/Makefile.maint +++ b/Makefile.maint @@ -1,6 +1,6 @@ ## Makefile.maint -- Makefile rules for libtool maintainers -*-Makefile-*- ## -## Copyright (C) 2004, 2005 Free Software Foundation, Inc. +## Copyright (C) 2004, 2005, 2010 Free Software Foundation, Inc. ## Written by Scott James Remnant, 2004 ## ## This file is part of GNU Libtool. @@ -39,11 +39,11 @@ TEXI2HTML = texi2html .PHONY: git-release git-release: version-check prev-tarball check-news fetch git-dist diffs web-manual @tarname="$(PACKAGE)-$(VERSION).tar.gz"; \ - lzmaname="$(PACKAGE)-$(VERSION).tar.lzma"; \ + xzname="$(PACKAGE)-$(VERSION).tar.xz"; \ diffname="$(PACKAGE)-$(LASTRELEASE)-$(VERSION).diff.gz"; \ echo " *** Upload $$tarname, $$tarname.sig,";\ - echo " *** $$tarname.directive.asc, $$lzmaname,";\ - echo " *** $$lzmaname.sig, $$lzmaname.directive.asc,";\ + echo " *** $$tarname.directive.asc, $$xzname,";\ + echo " *** $$xzname.sig, $$xzname.directive.asc,";\ echo " *** $$diffname, $$diffname.sig";\ echo " *** and $$diffname.directive.asc to either"; \ echo " *** /incoming/alpha or /incoming/ftp on ftp-upload.gnu.org." @@ -134,7 +134,7 @@ git-dist: check-news check-commit cd $(srcdir) \ && $(GIT) tag -s "v$(VERSION)" ## Generate signatures and directives for FSF ftp-upload: - for suffix in gz lzma; do \ + for suffix in gz xz; do \ ofile="$(PACKAGE)-$(VERSION).tar.$$suffix"; \ $(GPG) --detach-sign $$ofile \ && echo "version: 1.1" > $$ofile.directive \ @@ -151,7 +151,7 @@ prev-tarball: then echo "LASTRELEASE is not set"; exit 1; fi @ofile="$(PACKAGE)-$(LASTRELEASE).tar.gz"; \ if test -f $$ofile; then :; \ - else ofile="$(PACKAGE)-$(LASTRELEASE).tar.lzma"; \ + else ofile="$(PACKAGE)-$(LASTRELEASE).tar.xz"; \ if test -f $$ofile; then :; \ else echo "Cannot make diffs without $$ofile"; exit 1; fi; fi @@ -160,7 +160,7 @@ new-tarball: ## Make sure we have the new release tarball in the tree. @ofile="$(PACKAGE)-$(VERSION).tar.gz"; \ if test -f $$ofile; then :; \ - else ofile="$(PACKAGE)-$(VERSION).tar.lzma"; \ + else ofile="$(PACKAGE)-$(VERSION).tar.xz"; \ if test -f $$ofile; then :; \ else echo "Cannot make diffs without $$ofile"; exit 1; fi; fi @@ -179,8 +179,8 @@ diffs: prev-tarball new-tarball ntar="../$(PACKAGE)-$(VERSION).tar"; \ test -f "$$otar.gz" && otar="$$otar.gz" && ounpack="gzip"; \ test -f "$$ntar.gz" && ntar="$$ntar.gz" && nunpack="gzip"; \ - test -f "$$otar.lzma" && otar="$$otar.lzma" && ounpack="lzma"; \ - test -f "$$ntar.lzma" && ntar="$$ntar.lzma" && nunpack="zlma"; \ + test -f "$$otar.xz" && otar="$$otar.xz" && ounpack="xz"; \ + test -f "$$ntar.xz" && ntar="$$ntar.xz" && nunpack="xz"; \ $$ounpack -c -d "$$otar" | tar xf - \ &&am
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
[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
---
> 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
+
+ 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
Ralf Wildenhues
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 --- 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 + 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 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:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? diff --git i/Makefile.am w/Makefile.am index 6e29a29..f74708c 100644 --- i/Makefile.am +++ w/Makefile.am @@ -327,8 +327,10 @@ update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
On 09/22/2010 12:22 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. Any ideas on how to avoid such a race? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [patch] 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: 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 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: [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 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 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 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 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] 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: [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: 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: 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: [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: [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 > --- > 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 v5 2/2] git-version-gen: add --fallback option to use if git is not present
On 12/28/2012 04:45 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. > (scriptversion): Update. > > Copyright-paperwork-exempt: yes > Signed-off-by: Peter Rosin > --- > build-aux/git-version-gen |9 +++-- > 1 files changed, 7 insertions(+), 2 deletions(-) Now pushed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fixed -fvisbility=hidden typo in a comment
On 11/17/2014 10:58 AM, Gary V. Vaughan wrote: > Hi Vincent, > >> On 17 Nov 2014, at 17:29, Vincent Lefevre wrote: >> >>> On 2014-11-17 16:01:18 +, Gary V. Vaughan wrote: >>> Nice catch! I had no idea people scrutinized the comments so carefully :-) >> >> It was actually reported by Kiyoshi KANAZAWA in the GNU MPFR list: >> >> http://comments.gmane.org/gmane.comp.lib.mpfr.general/2246 >> >> BTW, some typos can be found by using "codespell". > > Great tip, thanks, I wasn't aware of that tool. > >> There are other >> ones in libtool, e.g. in NEWS: >> >> NEWS:607: propogate ==> propagate >> NEWS:1101: modeled ==> modelled > > The latter is a legitimate spelling (according to my British English > dictionary at least), > but unfortunately the NEWS file is checksummed to prevent changes after a > release, > so not easy to fix without tweaking the release process :-( It's possible to update the expected checksum when intentionally correcting old news entries. Since you are using gnulib's maint.mk, look at the update-NEWS-hash target. -- 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] 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] 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 > 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: 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
> 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: 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: [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: [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: 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: 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: [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: [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] 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
patch for `make install'
When installing branch-2-0 after a default `configure; make', bugs in
Makefile.am cause the following interesting output:
[...]
rm -rf /usr/local/share/libtool
/home/eblake/libtool/config/install-sh -d /libltdl
( cd ./libltdl && /bin/bash /home/eblake/libtool/config/missing --run tar chf -
COPYING.LIB README Makefile.am Makefile.in argz_.h argz.c configure.ac
configure libltdl/lt__alloc.h libltdl/lt__dirent.h libltdl/lt__glibc.h
libltdl/lt__private.h libltdl/lt__strl.h libltdl/lt_dlloader.h
libltdl/lt_error.h libltdl/lt_system.h libltdl/slist.h loaders/dld_link.c
loaders/dlopen.c loaders/dyld.c loaders/load_add_on.c loaders/loadlibrary.c
loaders/preopen.c loaders/shl_load.c lt__alloc.c lt__dirent.c lt__strl.c
lt_dlloader.c lt_error.c ltdl.c ltdl.h slist.c; ) \
| ( umask 0 && cd /libltdl && /bin/bash /home/eblake/libtool/config/missing
--run tar xf -; )
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
WARNING: I can't seem to be able to run `tar' with the given arguments.
You may want to install GNU tar or Free paxutils, or check the
command line arguments.
[...]
Whoops - we just installed to /libltdl instead of
/usr/local/share/libtool/libltdl, and libltdl/configure doesn't exist. The bug
exists in HEAD also. (If configure really should exist in libltdl, then there
is a bigger bug in how to have Makefile.am ensure that it is created before
`make install' is called, that I am not sure how to solve).
2005-04-20 Eric Blake <[EMAIL PROTECTED]> (tiny change)
* Makefile.am (ltdldatadir): Fix typo.
(ltdldatafiles): Skip configure.
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.130.2.11
diff -u -b -r1.130.2.11 Makefile.am
--- Makefile.am 4 Apr 2005 12:29:51 - 1.130.2.11
+++ Makefile.am 20 Apr 2005 21:30:37 -
@@ -184,11 +184,11 @@
## These are installed as a subdirectory of pkgdatadir so that
## libtoolize --ltdl can find them later:
-ltdldatadir= $(pkgvdatadir)/libltdl
+ltdldatadir= $(pkgdatadir)/libltdl
ltdldatafiles = COPYING.LIB README \
Makefile.am Makefile.in \
argz_.h argz.c \
- configure.ac configure \
+ configure.ac \
libltdl/lt__alloc.h \
libltdl/lt__dirent.h \
libltdl/lt__glibc.h \
--
Eric Blake
Re: FYI: remove stale reference to libltdl/loaders/Makefile [libtool--gary--1.0--patch-22]
Gary V. Vaughan gnu.org> writes: > > Commited to HEAD. > > * libltdl/configure.ac (AC_OUTPUT): loaders/Makefile is no longer > used. > This is needed on branch-2-0 as well.
Re: small abstractions: func_source,func_execute_cmds
Ralf Wildenhues gmx.de> writes:
> +# func_source file noexe
> +# Source FILE, adding directory component if necessary.
> +# If noexe is given, add a dot to prevent `$file.exe' from
> +# being sourced on system with automatic-append-.exe behavior.
> +func_source ()
> +{
> +$opt_debug
> +case $2,$build in
> +noexe,*cygwin* | noexe,*mingw*)
> + func_source_file=$1. ;;
> +*) func_source_file=$1 ;;
This is wrong for cygwin. For starters, cygwin does not auto-append .exe when
sourcing a file, but correctly sources the filename as it was spelled. (.exe
is auto-appended when exec()ing an executable, but sourcing is different from
exec()ing.)
$ echo echo plain > bar
$ echo echo exe > bar.exe
$ . bar
plain
$ . bar.
plain
$ . bar.exe
exe
$ echo echo only > only.exe
$ . only
bash: ./only: No such file or directory
Furthermore, appending a trailing . does not always work in cygwin. Cygwin has
the concept of managed mounts (where case distinctions are legal, and all
characters and spellings normally forbidden by Windows are made possible by
managed name munging under the hood; the only exceptions are that \ is still a
dirsep instead of a filename character, and that a filename like a: is still
absolute so you need ./a: instead). On a managed mount, trailing . is not
stripped, so adding a trailing dot with the excuse of suppressing .exe magic
breaks:
$ cd managed/
/home/eblake/managed
$ echo echo plain > bar
$ . bar
plain
$ . bar.
bash: bar.: No such file or directory
> +esac
> +case $func_source_file in
> +*/* | *\\*) . "$func_source_file" ;;
> +*) . "./$func_source_file" ;;
> +esac
> +}
> +
> +
...
>
> - # To insure that "foo" is sourced, and not "foo.exe",
> - # finese the cygwin/MSYS system by explicitly sourcing "foo."
> - # which disallows the automatic-append-.exe behavior.
> - case $build in
> - *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
> - *) wrapperdot=${wrapper} ;;
> - esac
> - # If there is no directory component, then add one.
> - case $file in
> - */* | *\\*) . ${wrapperdot} ;;
> - *) . ./${wrapperdot} ;;
> - esac
> + func_source "$wrapper" noexe
OK, so your refactoring did not introduce the bug; it was already present. But
it still needs to be fixed.
--
Eric Blake
Re: wrapperdot on cygwin (was: small abstractions: func_source, func_execute_cmds)
> > > > This is wrong for cygwin. For starters, cygwin does not auto-append .exe > > when > > sourcing a file, but correctly sources the filename as it was spelled. > > (.exe > > is auto-appended when exec()ing an executable, but sourcing is different > > from > > exec()ing.) > > Thanks for this information! So when have things changed between > http://lists.gnu.org/archive/html/libtool-patches/2003-01/msg9.html > and now? I mean, Charles won't have introduced this for no reason, with > this detailed comment added to it, and explaining this: > | There are two places in ltmain.sh where the shell wrapper is directly > | sourced. This doesn't work very well, because when both "foo" and > | "foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad. My earlier example was with sourcing, where the filename has no magic applied to it. The behavior is different if you want to execute a file (here, on a non-managed mount): $ cat > bar #!/bin/sh echo plain $ # Windows chokes if a file named bar.exe is a script instead of $ # an actual native executable, so I compiled a quickie: $ file bar.exe bar.exe: PE executable for MS Windows (console) Intel 80386 32-bit $ chmod u+x bar $ sh ./bar plain $ sh ./bar. plain $ sh ./bar.exe exe $ ./bar. plain $ ./bar exe $ ./bar.exe exe I don't know of any way to force execution of bar when both bar and bar.exe exist on a managed mount, but when bar is not a script. Fortunately, for libtool's usage, bar is a script, so you can force execution by invoking it with a shell. > > MinGW still works this way, right? Sorry, but I don't use mingw often enough to know. Someone else will have to field this question. > > Can we find out whether the file lives on a managed mount? I haven't found a way to do that, yet. > Or can we just turn off adding a dot for all of cygwin? > Or just for new cygwin versions? Probably the safest course, for now. It would certainly need testing, whatever happens. -- Eric Blake
Re: wrapperdot on cygwin (was: small abstractions: func_source, func_execute_cmds)
> Thanks for this information! So when have things changed between
> http://lists.gnu.org/archive/html/libtool-patches/2003-01/msg9.html
> and now? I mean, Charles won't have introduced this for no reason, with
> this detailed comment added to it, and explaining this:
> | There are two places in ltmain.sh where the shell wrapper is directly
> | sourced. This doesn't work very well, because when both "foo" and
> | "foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
When Charles' patch was originally introduced, cygwin did not have
managed mounts, which is why the trailing dot used to always work.
It was the later introduction of managed mounts that makes trailing
dot behavior inconsistent. I'm not sure if there was also a behavior
change about open("foo", O_RDONLY) preferring foo over foo.exe
(used by sourcing), vs. execl("foo", "foo", NULL) preferring foo.exe
over foo, but my recollection is that the dichotomy has always been
that way. So it may have been that Charles wrote the patch based
on exec behavior, without checking the difference in sourcing behavior.
At any rate, current behavior is that on cygwin, with bash, ash, ksh, or
zsh, `. ./foo' prefers foo over foo.exe, no trailing dot needed.
> Can we find out whether the file lives on a managed mount?
I suppose it is possible to parse the output of the cygwin mount
command, to see if the mount point of the current directory or its
ultimate mounted parent is managed, but that is error-prone. It
would be much easier to avoid using trailing dot in cygwin in the
first place.
> Or can we just turn off adding a dot for all of cygwin?
> Or just for new cygwin versions?
Cygwin developers (the people using libtool on cygwin) tend to
have pretty up-to-date installations - support on the cygwin
mailing list for anything over 6 months old is categorically "upgrade
your installation". So even if the behavior has changed from what
it was in the past, I don't think you have to go to any great lengths
to support old vs. new cygwin behaviors - just support the current
behavior, and tell people that libtool on cygwin requires the latest
cygwin.
--
Eric Blake
Re: cygwin build problem with m4 HEAD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 9/9/2005 1:31 AM:
>>ltdl.c, in lt_argz_insert, blindly calls argz_insert without checking whether
>>the before argument is NULL. But newlib (up until my patch posted there
>>today
>>is incorporated, http://sources.redhat.com/ml/newlib/2005/msg00516.html)
>>treated this as EINVAL, thus breaking load_deplibs() and failing every single
>>testcase of the m4 testsuite because of a failure to initialize.
>
> Thank you so much for analyzing this and providing a fix, I owe you a
> beer for that one!
>
> Your fix is not quite appropriate for inclusion, however, because our
> replacement argz.c does not provide argz_add. Does newlib have a
> similar bug in argz_append?
No - the newlib bug in argz_insert was that it called argz_add and
correctly appended the string, but then a missing return statement made it
fall through to the next line which checked for before being out of range,
such that it returned EINVAL on success, and overwrote the proper ENOMEM
on failure. Adding the return statement fixed newlib, although that means
there are systems in the wild (such as cygwin 1.5.18) with the bug based
on when they compiled newlib. I checked newlib's argz_append, and it
works just fine.
> If not, then the patch below should work as
> well, I believe (untested with newlib), and is less work than providing
> argz_add as well. Could you confirm this? If ok, I'll apply this CVS
> HEAD and backport to branch-1-5.
Don't apply the patch as is - I've thought about it a bit more. I think a
better patch, in the spirit of gnulib, is to update m4/argz.m4 to do a
configure-time run test to see if the system argz_insert is broken, in
which case libtool's argz_insert is used instead. Leave libtool's ltdl.c
alone - no need to dirty it with workarounds that can be solved by fixing
argz_insert instead. Besides, if any other project uses gnulib's argz
module, they should get correct behavior as well. Unfortunately, I
imagine that such a fix to the argz.m4 file will have to be pessimistic
during cross-compiles, and is further complicated by the fact that argz.c
should probably provide only a replacement argz_insert that falls back on
the system argz_append if it was only the system argz_insert that is
broken. However, my employer has not signed a copyright disclaimer,
despite my repeated requests (although I'm making progress, and hope to
get it one of these days), and the amount of m4 magic needed to add a
runtime check and improve argz.c is most likely beyond the trivial patch
limits.
>
> By the way, how does the m4 testsuite fare on cygwin with this fixed?
It dropped from 76 failures (ie. every single test) down to 9 failures
(I'll post further info to the m4 lists).
>
> Cheers,
> Ralf
>
> * libltdl/ltdl.c (lt_argz_insert): Work around newlib argz_insert bug.
> * Makefile.am (VERSION_INFO): Bumped revision.
> Reported by Eric Blake <[EMAIL PROTECTED]>.
>
> Index: Makefile.am
> ===
> RCS file: /cvsroot/libtool/libtool/Makefile.am,v
> retrieving revision 1.161
> diff -u -r1.161 Makefile.am
> --- Makefile.am 5 Sep 2005 06:21:48 - 1.161
> +++ Makefile.am 9 Sep 2005 07:21:02 -
> @@ -230,7 +230,7 @@
> AM_CPPFLAGS = -I. -I$(srcdir) -Ilibltdl -I$(srcdir)/libltdl \
> -I$(srcdir)/libltdl/libltdl
> AM_LDFLAGS = -no-undefined
> -VERSION_INFO = -version-info 6:0:0
> +VERSION_INFO = -version-info 6:1:0
>
> noinst_LTLIBRARIES = $(LT_DLLOADERS)
>
> Index: libltdl/ltdl.c
> ===
> RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
> retrieving revision 1.231
> diff -u -r1.231 ltdl.c
> --- libltdl/ltdl.c28 Jul 2005 10:01:03 - 1.231
> +++ libltdl/ltdl.c9 Sep 2005 07:21:02 -
> @@ -1,5 +1,5 @@
> /* ltdl.c -- system independent dlopen wrapper
> - Copyright (C) 1998, 1999, 2000, 2004 Free Software Foundation, Inc.
> + Copyright (C) 1998, 1999, 2000, 2004, 2005 Free Software Foundation, Inc.
> Originally by Thomas Tanner <[EMAIL PROTECTED]>
>
> NOTE: The canonical source of this file is maintained with the
> @@ -1445,7 +1445,12 @@
> {
>error_t error;
>
> - if ((error = argz_insert (pargz, pargz_len, before, entry)))
> + if (before)
> +error = argz_insert (pargz, pargz_len, before, entry);
> + else
> +error = argz_append (pargz, pargz_len, entry, 1 + strlen (entry));
> +
> + if (error)
> {
>switch (error)
> {
>
- --
Life is short - so eat dessert fir
compiler warning fixes for cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiling with -Wall -Werror often turns up some interesting bugs. The
whitespace in this file is also a bit screwy, according to emacs
whitespace mode.
libltdl/loaders/loadlibrary.c: In function `vm_open':
libltdl/loaders/loadlibrary.c:138: warning: implicit declaration of
function `cygwin_conv_to_full_win32_path'
libltdl/loaders/loadlibrary.c:161: warning: suggest parentheses around
assignment used as truth value
libltdl/loaders/loadlibrary.c:95: warning: unused variable `errormsg'
make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1
2005-09-22 Eric Blake <[EMAIL PROTECTED]> (tiny change)
* libltdl/loaders/loadlibrary.c (vm_open): Silence gcc warnings.
[__CYGWIN__]: Include for prototype.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDM2Gm84KuGfSFAYARAhyqAJ9r+zho9EJD5MT7GbPN0YJ4pmdAdwCgnSjw
VbXtqZtycztefMQ4KDNc2so=
=GE6a
-END PGP SIGNATURE-
Index: libltdl/loaders/loadlibrary.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/loadlibrary.c,v
retrieving revision 1.8
diff -u -p -b -r1.8 loadlibrary.c
--- libltdl/loaders/loadlibrary.c 28 Jul 2005 10:15:57 - 1.8
+++ libltdl/loaders/loadlibrary.c 23 Sep 2005 01:57:52 -
@@ -1,5 +1,5 @@
/* loader-loadlibrary.c -- dynamic linking for Win32
- Copyright (C) 1998, 1999, 2000, 2004 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2000, 2004, 2005 Free Software Foundation, Inc.
Originally by Thomas Tanner <[EMAIL PROTECTED]>
NOTE: The canonical source of this file is maintained with the
@@ -30,6 +30,10 @@ Foundation, Inc., 51 Franklin Street, Fi
#include "lt__private.h"
#include "lt_dlloader.h"
+#if defined(__CYGWIN__)
+# include
+#endif
+
/* Use the preprocessor to rename non-static symbols to avoid namespace
collisions when the loader code is statically linked into libltdl.
Use the "_LTX_" prefix so that the symbol addresses can
@@ -92,7 +96,6 @@ static lt_module
vm_open (lt_user_data loader_data, const char *filename)
{
lt_modulemodule = 0;
- const char *errormsg = 0;
char*searchname = 0;
char*ext;
char self_name_buf[MAX_PATH];
@@ -158,7 +161,7 @@ vm_open (lt_user_data loader_data, const
{
lt__handle *cur= 0;
-while (cur = (lt__handle *) lt_dlhandle_next ((lt_dlhandle) cur))
+while ((cur = (lt__handle *) lt_dlhandle_next ((lt_dlhandle) cur)))
{
if (!cur->module)
{
bootstrap warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On a fresh CVS checkout, ./bootstrap emits some unnecessary warnings: find: warning: you have specified the -depth option after a non-option argument (, but options are not positional (-depth affects tests specified before it as well as those specified after it). Please specify options before other arguments. diff: ./stamp-vcl: No such file or directory Patched thusly: 2005-10-26 Eric Blake <[EMAIL PROTECTED]> * Makefile.am (vcl-tmp): Avoid warnings from diff. * bootstrap: Avoid warnings from find. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDX3qG84KuGfSFAYARArL9AKCm04KoZSzELQyu5VfggvKNdpWITQCfYaWH ibUOidU+T1MJV89VYkjLKhw= =SvoM -END PGP SIGNATURE-
Re: bootstrap warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 10/26/2005 6:46 AM:
>
> 2005-10-26 Eric Blake <[EMAIL PROTECTED]>
>
> * Makefile.am (vcl-tmp): Avoid warnings from diff.
> * bootstrap: Avoid warnings from find.
>
It would help if I actually attached the patch :-/
Also, emacs whitespace-cleanup doesn't like the fact that bootstrap has
space followed by a literal tab in my_sed_traces; and it tried to 'help'
me by flattening that into a single tab (of course, changing the sed
expression in the process). Is it safe to use \t instead of literal tab
in a sed expression?
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDX3yu84KuGfSFAYARAlL5AKCSZQPzv8ZOqkP9zYD1CVWU0eSHXgCfeEMz
komn6T+pXSVaLHgDLUB2ju8=
=9zcs
-END PGP SIGNATURE-
Index: bootstrap
===
RCS file: /cvsroot/libtool/libtool/bootstrap,v
retrieving revision 1.71
diff -u -p -b -r1.71 bootstrap
--- bootstrap 26 Oct 2005 10:42:03 - 1.71
+++ bootstrap 26 Oct 2005 12:50:39 -
@@ -65,7 +65,7 @@ WARNING: them with all m4 file as shippe
WARNING: `lt~obsolete.m4'). After that, retry this bootstrap.
EOF
-find . \( -name autom4te.cache -o -name libtool \) -depth -print \
+find . -depth \( -name autom4te.cache -o -name libtool \) -print \
| grep -v '{arch}' \
| xargs rm -rf
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.173
diff -u -p -b -r1.173 Makefile.am
--- Makefile.am 26 Oct 2005 10:42:02 - 1.173
+++ Makefile.am 26 Oct 2005 12:50:39 -
@@ -138,7 +138,7 @@ $(srcdir)/stamp-vcl: vcl-tmp clean-ltmai
vcl-tmp:
@set dummy `$(MKSTAMP) < $(srcdir)/ChangeLog`; shift; \
echo "$$1" > vcl.tmp; \
- diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null \
+ diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null 2>/dev/null \
|| (echo "Updating stamp-vcl"; cp vcl.tmp $(srcdir)/stamp-vcl)
[EMAIL PROTECTED] -f vcl.tmp
Re: FYI: bootstrap warning
> Hi Eric, > > > * bootstrap: Avoid warnings from find. > > Which find version is this? findutils-4.2.25 (the latest stable version, and the default on cygwin) -- Eric Blake
Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff
CVS head is currently broken on cygwin. It looks like the patch to rename lt_dlhandle_next to lt_dlhandle_iterate was incomplete. $ make CFLAGS='-g2 -Wall -Werror' ... make[2]: Entering directory `/home/eblake/libtool' depbase=`echo libltdl/loaders/loadlibrary.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -DHAVE_CONFIG_H -DLT_CONFIG_H='' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g2 -Wall -Werror -MT libltdl/loaders/loadlibrary.lo -MD -MP -MF "$depbase.Tpo" -c -o libltdl/loaders/loadlibrary.lo libltdl/loaders/loadlibrary.c; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I. -DHAVE_CONFIG_H "-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g2 -Wall -Werror -MT libltdl/loaders/loadlibrary.lo -MD -MP -MF libltdl/loaders/.deps/loadlibrary.Tpo -c libltdl/loaders/loadlibrary.c -DPIC -o libltdl/loaders/.libs/loadlibrary.o libltdl/loaders/loadlibrary.c: In function `vm_open': libltdl/loaders/loadlibrary.c:164: warning: implicit declaration of function `lt_dlhandle_next' make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1 -- Eric Blake
Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff
Gary V. Vaughan gnu.org> writes:
> -lt_dlhandle_next (lt_dlhandle place)
> +lt_dlhandle_iterate (lt_dlinterface_id iface, lt_dlhandle place)
>{
> lt__handle *handle = (lt__handle *) place;
> + lt__interface_id *iterator = (lt__interface_id *) iface;
> +
> + assert (iface); /* iface is a required argument */
>
> if (!handle)
> -{
> - /* old style iteration across all handles */
> - iterator = 0;
> - handle = (lt__handle *) handles;
> -}
> - else
> -{
> - /* otherwise start at the next handle after the passed one */
> - handle = handle->next;
> -}
> +handle = (lt__handle *) handles;
>
> - /* advance until the interface check (if we have one) succeeds */
> - while (handle && iterator && iterator->iface
> + /* advance while the interface check fails */
> + while (handle && iterator->iface
>&& ((*iterator->iface) (handle, iterator->id_string) != 0))
>{
> handle = handle->next;
>}
This doesn't look right to me; it looks like you are heading into an infinite
loop with the usage idiom suggested in the manual (handle = lt_dlhandle_iterate
(iter, handle);) because the passed-in place is returned without advancing
through the list.
Shouldn't this have been:
if (!handle)
handle = (lt__handle *) handles;
else
handle = handle->next;
/* advance while the interface check fails */
...
--
Eric Blake
Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff
> Hi Eric,
>
> * Eric Blake wrote on Wed, Oct 26, 2005 at 05:11:57PM CEST:
> > CVS head is currently broken on cygwin. It looks like the patch
> > to rename lt_dlhandle_next to lt_dlhandle_iterate was incomplete.
>
> Yep. And we see me goofing up once more: loadlibrary.c:vm_open()
> really _has_ to iterate over _all_ modules. One could argue this to be
> internal use, but we do rely on this now-undocumented detail of
> lt_dlhandle_iterate here.
Something I'm trying right now is
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.236
diff -u -b -r1.236 ltdl.c
--- libltdl/ltdl.c 26 Oct 2005 10:26:48 - 1.236
+++ libltdl/ltdl.c 26 Oct 2005 20:12:55 -
@@ -2125,6 +2125,8 @@
if (!handle)
handle = (lt__handle *) handles;
+ else
+handle = handle->next;
/* advance while the interface check fails */
while (handle && iterator->iface
Index: libltdl/loaders/loadlibrary.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/loadlibrary.c,v
retrieving revision 1.9
diff -u -b -r1.9 loadlibrary.c
--- libltdl/loaders/loadlibrary.c 23 Sep 2005 07:58:42 - 1.9
+++ libltdl/loaders/loadlibrary.c 26 Oct 2005 20:12:55 -
@@ -160,8 +160,9 @@
find one. */
{
lt__handle *cur= 0;
+lt_dlinterface_id all= lt_dlinterface_register ("all", NULL);
-while ((cur = (lt__handle *) lt_dlhandle_next ((lt_dlhandle) cur)))
+while ((cur = (lt__handle *) lt_dlhandle_iterate (all, (lt_dlhandle) cur)))
{
if (!cur->module)
{
Hmm, lt_dlinterface_register leads to a memory leak; so my patch
idea above is incomplete. We also need something like:
lt_dlinterface_unregister (lt_dlinterface_id)
{
lt__free ((lt__interface_id *) lt_dlinterface_id);
}
>
> Now that I look at it, there's potential for more subtle breakage in
> loadlibrary.c, but this one independent of our recent changes:
>
> | /* Append a `.' to stop Windows from adding an
> | implicit `.dll' extension. */
> | searchname = MALLOC (char, 2+ LT_STRLEN (filename));
> | if (searchname)
> | sprintf (searchname, "%s.", filename);
> ...
> | #if defined(__CYGWIN__)
> | {
> | char wpath[MAX_PATH];
> | cygwin_conv_to_full_win32_path (searchname, wpath);
> | module = LoadLibrary (wpath);
> | }
> | #else
> | module = LoadLibrary (searchname);
> | #endif
Why is cygwin even trying to use LoadLibrary? Cygwin comes
with dlopen(), after all.
>
> Does `cygwin_conv_to_full_win32_path' DTRT the right thing on cygwin
> managed mounts? (Where The Right Thing[tm] is here defined as: do what
> we expect it to :)
I hope so.
Not quite. On a managed mount, cygwin_conv_to_full_win32_path
(searchname, wpath); correctly returns the munged underlying
Windows name, but earlier in the code, you appended a trailing
dot. Since a managed mount munges the trailing dot, you are
now trying to load (for example) "c:\cygwin\managed\libfoo%2E",
rather than "c:\cygwin\managed\libfoo.", so the call to LoadLibrary
won't see a trailing dot and will thus append an implicit ".dll".
--
Eric Blake
Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff
> > Not quite. On a managed mount, cygwin_conv_to_full_win32_path > (searchname, wpath); correctly returns the munged underlying > Windows name, but earlier in the code, you appended a trailing > dot. Since a managed mount munges the trailing dot, you are > now trying to load (for example) "c:\cygwin\managed\libfoo%2E", > rather than "c:\cygwin\managed\libfoo.", so the call to LoadLibrary > won't see a trailing dot and will thus append an implicit ".dll". On the other hand, I just had a thought. If you were to wait to append the trailing dot until after you have converted to the Windows name, this idiom of using a trailing dot to supress implicit .dll should then work just fine for using LoadLibrary even inside cygwin managed mounts. -- Eric Blake
Re: FYI: THANKS updated
Ralf Wildenhues gmx.de> writes: > * THANKS: Updated. > > + Eric Blake ericblake comcast.net Please list me as [EMAIL PROTECTED] (not only is it shorter to type, but it is set up to forward correctly even if I change ISPs, which I have been known to do). -- Eric Blake
Re: cygwin dlopening backends
Ralf Wildenhues gmx.de> writes:
>
> Hi Charles, Eric,
Hi Ralf,
>
> * Charles Wilson wrote on Thu, Nov 10, 2005 at 05:55:28AM CET:
> > Ralf Wildenhues wrote:
> > >
> > >There are several separate issues here:
> > >
> > >1) lt_dlhandle_iterate breakage of loadlibrary.c
> > >2) needed dlinterface_free (or maybe _unregister?)
> > > including documentation
> > >3) cygwin managed mount fix of loadlibrary.c
> > > or remove the cygwin-specific code of loadlibrary.c
> > >4) use either
> > >- only dlopen, or
> > >- first dlopen, then LoadLibrary
> > > on cygwin, or
> > >- make the choice configurable
> >
> > I think Ralf's issues (1) and (2) need fixing first
>
> Please take a look at and test the following patches which should
> address (1), (2), and (3). I have not done a lot testing myself /yet/,
> so beware.
In general, it looks good to me. Minor nits below. I'll try running it through
the full testsuite, but it may take me a while.
>
> I'm not so sure whether we should register/free the thing in loadlibrary
> every time instead of once at the start: those memory checker users
> always go nuts when they find a small, constant-amount of allocated
> memory not freed before exit().
> (OTOH, we might be lucky in that there aren't any good checkers -- at
> least that I know of -- for mingw or cygwin
I'm fine with your approach of creating it just once, because you maintain a
handle to it. If you are really worried about a memory leak, use an atexit()
function to clean up after yourself.
>
> Also, I wasn't sure whether paths on w32 (all incarnations) can be bound
> by MAX_PATH. The documentation for cygwin_conv_to_full_win32_path
> suggests that at least for cygwin this is safe.
Yes, the cygwin_conv* functions are bounded by MAX_PATH. I would much rather
have an interface that does not have an implicit, arbitrary length (preferring
either the user passes in the max length of a pre-allocated buffer, or the
function itself does the malloc), but that was not done in this case.
Currently, MAX_PATH on cygwin is 256 (okay by strict POSIX but not by XSI
standards) because of corresponding limits in the ASCII versions of Windows
syscalls. There is talk (but just that, because it would be a huge patch,
particularly while maintaining backward compatibility) of switching cygwin to
use the Unicode version of Windows syscalls on NT machines (with suitable
fallbacks for the 9x family which only supports ASCII), at which point MAX_PATH
would be increased to a more reasonable 32k on NT.
>
> +void lt_dlinterface_free (lt_dlinterface_id key)
> +{
> + lt__interface_id *interface_id = (lt__interface_id *)key;
> + FREE (interface_id->id_string);
> + FREE (interface_id);
> +}
This made me realize that there is another problem with lt_dlinterface_register:
2005-10-26 Eric Blake <[EMAIL PROTECTED]>
* libltdl/ltdl.c (lt_dlinterface_register): Fail if lt__strdup did.
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.236
diff -u -p -r1.236 ltdl.c
--- libltdl/ltdl.c 26 Oct 2005 10:26:48 - 1.236
+++ libltdl/ltdl.c 13 Nov 2005 04:35:45 -
@@ -2027,7 +2027,10 @@ lt_dlinterface_register (const char *id_
if (interface_id)
{
interface_id->id_string = lt__strdup (id_string);
- interface_id->iface = iface;
+ if (!interface_id->id_string)
+ FREE (interface_id);
+ else
+ interface_id->iface = iface;
}
return (lt_dlinterface_id) interface_id;
> +static lt_dlinterface_id iface_id = 0;
> +
> +static int
> +loadlibrary__module_interface (lt_dlhandle handle, const char *id_string)
> +{
> + /* we _need_ to look at every module, so pretend all belong to us */
> + return 0;
> +}
Hmm, you are actually registering a no-op function, even though
lt_dlhandle_iterate behaves the same (although slightly faster) had you
registered a NULL pointer instead as in my original version of the patch. But I
guess that is okay, in case we ever change lt_dlinterface_register to require a
non-NULL function.
> -99,6 +110,7
>char *searchname = 0;
>char *ext;
>char self_name_buf[MAX_PATH];
> + char wpath[MAX_PATH];
If cygwin ever increases MAX_PATH beyond 256, self_name_buf and wpath together
would become a huge burden on the stack.
>
>if (!filename)
> {
> -109,24 +121,33
> }
>else
> {
> - ext = strrchr (filename, '.');
> -}
> + if (LT_STRLEN (filename) >= MAX_PATH)
./bootstrap --help
Inspired by GNU coding standards, and by the example of CVS tar,
I propose patching bootstrap to be a little friendlier. I didn't know
what would make a good --version, so that is left for someone else
to provide.
2005-11-17 Eric Blake <[EMAIL PROTECTED]>
* bootstrap (--help): Provide some help.
Index: bootstrap
===
RCS file: /cvsroot/libtool/libtool/bootstrap,v
retrieving revision 1.72
diff -u -p -r1.72 bootstrap
--- bootstrap 26 Oct 2005 14:26:35 - 1.72
+++ bootstrap 18 Nov 2005 02:29:05 -
@@ -37,6 +37,21 @@ export SHELL
: ${MAKEINFO=makeinfo}
: ${WORKING_LIBOBJ_SUPPORT=false}
+if test $# = 1 ; then
+ case $1 in
+--help|-h*)
+ cat < 2.59) and automake (> 2.9.6).
+EOF
+ exit
+;;
+ esac
+fi
+
test -f ./configure.ac || {
echo "bootstrap: can't find ./configure.ac, please rerun from top_srcdir"
exit 1
--
Eric Blake
Re: ./bootstrap --help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christoph Egger on 11/18/2005 7:57 AM: >>+ (> 2.59) and automake (> 2.9.6). >>+EOF > > > hmm... I thought automake 1.9.6 is the latest version. Did I miss something? Nope, just a typo on my part. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfh6D84KuGfSFAYARAswHAKCVGTENq8zueYeA97CRkechjjD0/ACgsEYP tovZG9neVsQMTXva1T/0tF0= =+zb+ -END PGP SIGNATURE-
Re: fail to boostrap with CVS autoconf/automake
> Using latest CVS autoconf/automake I am encountering this sort of > problem when bootstrapping/configuring libtool: > > config.status: creating Makefile > config.status: creating config.h > config.status: executing tests/atconfig commands > config.status: executing depfiles commands > config.status: executing libtool commands > sed: can't read libltdl/config/ltmain.sh: No such file or directory > sed: can't read libltdl/config/ltmain.sh: No such file or directory > > In fact, while running the bootstrap script, there are complaints > about this "missing" file for every directory. I've seen this when I run ./bootstrap on an already bootstrapped tree. My solution is to use cvspurge (one of the cvsutils from http://www.red-bean.com/cvsutils/) to wipe the tree and start over, at which point it solves itself. But a fix that would allow ./bootstrap to run on an already bootstrapped tree would be nice. -- Eric Blake
Re: fail to boostrap with CVS autoconf/automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 12/7/2005 2:30 AM: >>>In fact, while running the bootstrap script, there are complaints >>>about this "missing" file for every directory. > > Am I correct that both of you do in-tree (non-VPATH) builds? Yes, I was doing an in-tree build, with GNU make 3.80. > Please try the patch below. > * bootstrap: always remove Makefile, to avoid triggering the > autotools rebuild rules before autoreconf builds these. > Reported by Bob Friesenhahn <[EMAIL PROTECTED]>. > That got it! Please commit. The only improvement I could offer is that if there is a config.status lying around because ./bootstrap was run in a preconfigured tree, then bootstrap could try running "./config.status - --recheck; ./config.status" to restore Makefile after so forcefully removing it. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFDluX684KuGfSFAYARAmaLAJ9n3eaLVVKl6BOYBswGvh5XU4n/CwCY0FOo 88/BN0kvTxed3gh6EQ== =qsUd -END PGP SIGNATURE-
compiler warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I. -DLTDLOPEN=libltdl
"-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl -I./libltdl
- -I./libltdl/libltdl -g2 -Wall -Werror -MT
libltdl/libltdl_libltdl_la-ltdl.lo -MD -MP -MF
libltdl/.deps/libltdl_libltdl_la-ltdl.Tpo -c libltdl/ltdl.c -DPIC -o
libltdl/.libs/libltdl_libltdl_la-ltdl.o
libltdl/ltdl.c: In function `lt_dlinterface_free':
libltdl/ltdl.c:2042: warning: passing arg 1 of `free' discards qualifiers
from pointer target type
make[2]: *** [libltdl/libltdl_libltdl_la-ltdl.lo] Error 1
So, should we change libltdl/libtldl/lt__alloc.h to have the FREE(mem)
macro cast away const by calling free ((void *) mem), or should we change
libltdl/ltdl.c so that lt__interface_id.id_string is just char* instead of
const char*, or should we do this nasty approach:
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.238
diff -u -p -r1.238 ltdl.c
- --- libltdl/ltdl.c 25 Nov 2005 18:42:28 - 1.238
+++ libltdl/ltdl.c 8 Dec 2005 13:47:30 -
@@ -2039,7 +2039,7 @@ lt_dlinterface_register (const char *id_
void lt_dlinterface_free (lt_dlinterface_id key)
{
lt__interface_id *interface_id = (lt__interface_id *)key;
- - FREE (interface_id->id_string);
+ FREE (*(char **) &interface_id->id_string);
FREE (interface_id);
}
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDmDnf84KuGfSFAYARAq3oAKCL2tSaSCaX+MZgmpFpfoA6oSGHswCfXxdM
gP05zzxx6jODbPkOi7uxKoc=
=VsoH
-END PGP SIGNATURE-
Re: compiler warning
> Hi Eric, Hi Ralf, > > So, should we change libltdl/libtldl/lt__alloc.h to have the FREE(mem) > > macro cast away const by calling free ((void *) mem), > > Yes, > I've applied this to HEAD. Except you forgot to bump the copyright year in lt__alloc.h. -- Eric Blake
Update CVS instructions
See http://savannah.gnu.org/forum/forum.php?forum_id=4168. The release notes for 1.5.22 have the wrong instructions. 2005-12-19 Eric Blake <[EMAIL PROTECTED]> * HACKING (release note templates): Update anon cvs location. Index: HACKING === RCS file: /sources/libtool/libtool/HACKING,v retrieving revision 1.25 diff -u -r1.25 HACKING --- HACKING 18 Dec 2005 22:50:31 - 1.25 +++ HACKING 19 Dec 2005 15:05:36 - @@ -506,7 +506,7 @@ anonymous cvs by using the following commands: $ export CVS_RSH=ssh - $ cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/libtool \ + $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/sources/libtool \ co -r @CVS_RELEASE_TAG@ libtool You will then need to have recent (possibly as yet unreleased) versions @@ -592,7 +592,7 @@ you are prompted for the password): $ export CVS_RSH=ssh - $ cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/libtool \ + $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/sources/libtool \ co -r @CVS_RELEASE_TAG@ libtool You will then need to have the latest release versions of Automake -- Eric Blake
Re: Update CVS instructions
Missed one. Apply this in addition to the previous mail. > > 2005-12-19 Eric Blake <[EMAIL PROTECTED]> > > * HACKING (release note templates): Update anon cvs location. > 2005-12-19 Eric Blake <[EMAIL PROTECTED]> * HACKING (release note templates): Update anon cvs location. * README.alpha (Reporting Bugs): Likewise. Index: README.alpha === RCS file: /sources/libtool/libtool/README.alpha,v retrieving revision 1.6 diff -u -r1.6 README.alpha --- README.alpha16 Dec 2005 16:50:00 - 1.6 +++ README.alpha19 Dec 2005 15:08:09 - @@ -20,7 +20,7 @@ problem, please try upgrading to the latest version from CVS first: export CVS_RSH=ssh - cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/libtool co libtool + cvs -z3 -d :pserver:[EMAIL PROTECTED]:/sources/libtool co libtool cd libtool ./bootstrap -- Eric Blake
Re: Update CVS instructions
> CVS itself recommended a hostname of 'cvs.savannah.gnu.org'. So that > is what I am using now. The announcement on savannah, from the link in my original mail, pointed out that cvs.sv.gnu.org is a shorter hostname with the same IP address as cvs.savannah.gnu.org, for convenience. Either spelling is fine by me, as long as HACKING and README.alpha are consistent and point to an actual repository for anonymous access. -- Eric Blake
Re: Update CVS instructions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, According to Ralf Wildenhues on 12/19/2005 9:31 AM: > >>Missed one. Apply this in addition to the previous mail. > > > D'oh. I don't know how I could forget that. :-( > > Thanks for the patch, applied to both branches. You got the correct ChangeLog, but only applied my patch to HACKING. You need to also apply my second patch to fix README.alpha. > >>2005-12-19 Eric Blake <[EMAIL PROTECTED]> >> >> * HACKING (release note templates): Update anon cvs location. >> * README.alpha (Reporting Bugs): Likewise. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDqAVk84KuGfSFAYARAuuzAKC+fcqF3AI89H63QYlBq3BcvAvbTQCfbbjZ vP8gYtBQrZwq5xnTYMTYBAE= =e+C8 -END PGP SIGNATURE-
Re: FYI: update years
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 1/12/2006 12:43 AM: >> >>Isn't this a question of Copyright law, which easily trounces >>--version? > > > Correct. Please pretend I never wrote that sentence; all files in > question will definitely have relevant changes before the next release, > and those changes will happen this year. Furthermore, the GNU coding standards were recently updated, and http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices now states "To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you're using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year." So I think it might even be okay for a blanket addition of 2006 to every file in libtool that carries a copyright disclaimer, whether or not the file ends up being edited this year. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx68L84KuGfSFAYARAq7kAJ4w2jyelHmtfu/FtJaxOlXqcGemZACgppMM Z11/GL1hL9Dr00oRUDVIaWk= =URBt -END PGP SIGNATURE-
