The included regex cannot support equivalence classes and multibyte
collation symbols properly. On the other hand it supports 64-bit
regoff_t, which glibc cannot provide without breaking the ABI.
We currently favor the latter, but this is no longer correct since
there's clearly no hope of ever pas
Eric Blake wrote:
> here's the full
> trace, showing that /bin/sh is ultimately rejected and the script rerun
> under ksh for IRIX.
Thanks. And we know that ksh has a working 'alias' command, so that
gnulib-tool ends up getting a working 'echo' command in that shell.
Bruno
Jim Meyering wrote:
> Eric Blake wrote:
>> On 09/08/2010 03:17 PM, Jim Meyering wrote:
>>>
>>> +# Whether to reject a shell for which "set -x" corrupts stderr.
>>> +strict_=yes
>>> +
>>> +gl_set_x_corrupts_stderr_='$( (exec 3>&1; set -x; P=1 true 2>&3) 2>
>>> /dev/null)'
>>> +
>>> gl_shell_test
Ralf Wildenhues wrote:
> > (hmm, maybe autoconf should use that trick to reduce
> > forking at m4sh startup).
>
> exec 3>&2 2>/dev/null; command; exec 2>&3 3>&-
>
> has the advantage of not forking, the disadvantage of using another file
> descriptor (which we should probably disallow the user
Bruno Haible wrote:
>> They make it so with "set -x", environment settings
>> appear in stderr output. For example, this command:
>> /bin/sh -c 'set -x; P=1 true 2> err' 2>/dev/null; cat err
>> prints "P=1" on those two systems:
>
> This test disqualifies also 'ksh', which is considered the "g
On Sep 8, 2010, at 10:02 PM, Eric Blake wrote:
> On 09/08/2010 01:00 PM, Ben Abbott wrote:
>> I'd like to clone gnulib from behind my company's firewall.
>>
>> The ports for git and cvs are closed, so I tried http, and obtained the
>> error below.
>>
>> export http_proxy=...
>> git cl
On Sep 9, 2010, at 16:52 , ext Ben Abbott wrote:
> Thanks Eric.
>
> Cloning from ...
>
> git clone http://repo.or.cz/r/gnulib.git
>
> worked nicely. I liked the "insteadof" suggestion, but when I tried it I got
> the same error as before ... even though ~/.gitconfig has the substitution
Hello,
in working on GNU Inetutils I have been forced to observe
that the autoconfiguration fails for OpenBSD or FreeBSD
in two instances (for which I see a solution), and that
these ought to be mended by Gnulib.
Tests related to utmp and openpty/forkpty, which are activated
by the configure scri
On Sep 9, 2010, at 10:06 AM, Jarno Rajahalme wrote:
> On Sep 9, 2010, at 16:52 , ext Ben Abbott wrote:
>> Thanks Eric.
>>
>> Cloning from ...
>>
>> git clone http://repo.or.cz/r/gnulib.git
>>
>> worked nicely. I liked the "insteadof" suggestion, but when I tried it I got
>> the same err
On 09/09/2010 03:37 AM, Jim Meyering wrote:
@@ -269,7 +305,18 @@ path_prepend_()
setup_()
{
- test "$VERBOSE" = yes&& set -x
+ if test "$VERBOSE" = yes; then
+# Test whether set -x may cause the selected shell to corrupt an
+# application's stderr. Many do, including zsh-4.3.10 a
On 09/09/2010 02:18 AM, Paolo Bonzini wrote:
The included regex cannot support equivalence classes and multibyte
collation symbols properly. On the other hand it supports 64-bit
regoff_t, which glibc cannot provide without breaking the ABI.
We currently favor the latter, but this is no longer co
On 09/09/2010 05:04 PM, Eric Blake wrote:
Hmm - here's the current POSIX 2008 wording:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/regex.h.html#tag_13_38
The header shall define the regoff_t type as a signed integer
type that can hold the largest value that can be stored in eit
Eric,
> But you are right that on x86_64 glibc, we have:
> (gdb) p sizeof(regoff_t)
> $1 = 4
> (gdb) p sizeof(off_t)
> $2 = 8
> (gdb) p sizeof(ssize_t)
> $3 = 8
> (gdb) p sizeof(ptrdiff_t)
> $4 = 8
>
> Should we go back to the Austin Group to further relax the requirements
> on regoff_t to only
On 09/09/2010 05:24 PM, Bruno Haible wrote:
This would make no sense to me.
I know, I'm trying to be pragmatic. I prefer a gigabyte-crippled grep
than a feature-crippled grep.
It would be better to push the glibc people so that they offer some
preprocessor macro that makes regoff_t 64-bit
On 09/09/2010 08:44 AM, Paolo Bonzini wrote:
> The glibc bug at http://sourceware.org/bugzilla/show_bug.cgi?id=5945
> says "This is known but obviously cannot easily be fixed. Suspended
> until somebody takes this serious to actually take a stab at a solution".
>
> I guess that counts as "patche
Hello Mats,
Thank you for your reports. Can you please also say on which
versions of OpenBSD and FreeBSD you observed the problems?
I need this info for investigating and for documenting the issue.
Bruno
[adding bug-gnulib, after sanitizing some details]
On 09/09/2010 02:36 PM, Nelson H. F. Beebe wrote:
I got m4-1.4.15 to build on NetBSD 5.0.2 with this
source code patch, and change in compiler options:
% diff -c tests/test-strsignal.c.~1~ tests/test-strsignal.c
*** tests/test-strsignal.c.~1~
I'm getting this compilation failure, and haven't had time to look into
it further yet...
gcc -I. -I../lib -DIN_M4_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../lib
-I./../lib -g -O2 -MT test-langinfo.o -MD -MP -MF
.deps/test-langinfo.Tpo -c -o test-langinfo.o test-langinfo.c
test-langinfo.c:35
On 09/09/2010 02:44 PM, Eric Blake wrote:
Add -D_NETBSD_SOURCE to CFLAGS to expose the hidden prototype
of strsignal:
Hmm - I don't see _NETBSD_SOURCE listed in m4/extensions.m4; maybe that
means gl_USE_SYSTEM_EXTENSIONS needs to be aware of yet another spelling
to get this automatically added
Here's a proposed rewrite that tries to take all the comments in mind,
while trying to improve the prose a bit.
rms was fine with the proposed change to standards.texi. I installed it.
Thanks.
torsdag den 9 september 2010 klockan 21:39 skrev Bruno Haible detta:
> Hello Mats,
>
> Thank you for your reports. Can you please also say on which
> versions of OpenBSD and FreeBSD you observed the problems?
> I need this info for investigating and for documenting the issue.
>
> Bruno
The quic
* gnulib-tool (func_cache_var, func_cache_lookup_module)
(func_get_description, func_get_comment, func_get_status)
(func_get_notice, func_get_applicability, func_get_filelist)
(func_get_dependencies, func_get_autoconf_early_snippet)
(func_get_autoconf_snippet, func_get_automake_snippet)
(func_get_i
* m4/strsignal.m4 (gl_FUNC_STRSIGNAL): Also check in .
* lib/string.in.h (includes): Likewise.
* doc/posix-functions/strsignal.texi (strsignal): Document the
bug.
Reported by Nelson H. F. Beebe.
Signed-off-by: Eric Blake
---
Tested on NetBSD 5.0, and resolves the issue.
ChangeLog
On Thu, Sep 09, 2010 at 03:07:36PM -0600, Eric Blake wrote:
> I'm getting this compilation failure, and haven't had time to look into
> it further yet...
>
> gcc -I. -I../lib -DIN_M4_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../lib
> -I./../lib -g -O2 -MT test-langinfo.o -MD -MP -MF
> .deps/test
[ adding bug-autoconf ]
* Mats Erik Andersson wrote on Fri, Sep 10, 2010 at 12:19:08AM CEST:
> The quick punch lines first:
>
>* is __NOT__ self-contained, neither for OpenBSD, nor FreeBSD.
>
>* is __NOT__ self-contained for FreeBSD.
>
> In contrast,
>
>* __is__ self-containe
25 matches
Mail list logo
