Eric Blake wrote:
> I'm pretty sure that glibc has always worked with strerror(0).
Yes. I've checked my build logs collection and find no indication of
a problem on a glibc platform.
Regarding strerror, there is also the suboptimal cross-compilation guess:
checking for working strerror functio
> When cross-compiling, I also see this wrong guess:
>
> checking for signbit macro... guessing no
>
> This should fix it. (Most of this patch is merely reindentation.)
There is another wrong guess in the same file:
checking for signbit compiler built-ins... guessing no
This combined patch
I'm seeing this wrong guess on a glibc system:
checking whether ungetc works on arbitrary bytes... guessing no
2012-05-05 Bruno Haible
fseeko-tests, ftello-tests: Avoid "guessing no" when cross-compiling.
* m4/ungetc.m4 (gl_FUNC_UNGETC_WORKS): Require AC_CANONICAL_HOST. Whe
This cross-compilation guess is also suboptimal:
checking for d_ino member in directory struct... no
since d_ino is known to work on glibc/Linux since ever:
glibc/sysdeps/unix/sysv/linux/bits/dirent.h is essentially unchanged since
1997.
2012-05-05 Bruno Haible
d-ino: Avoid guessi
Another suboptimal cross-compilation guess is
checking whether tzset clobbers localtime buffer... yes
This fixes it.
2012-05-05 Bruno Haible
tzset: Avoid guessing wrong when cross-compiling to glibc systems.
* m4/tzset.m4 (gl_FUNC_TZSET_CLOBBER): Require AC_CANONICAL_HOST.
Another suboptimal cross-compilation guess is
checking whether link(2) dereferences a symlink... unknown
The only known platforms which show
checking whether link(2) dereferences a symlink... yes
are MacOS X, FreeBSD, NetBSD, OpenBSD, Minix, AIX, HP-UX, OSF/1.
Whereas on Linux and Cygwin syst
Another suboptimal cross-compilation guess is
checking for working nanosleep... cross-compiling
This test has 3 possible results:
- "yes", it works, no override needed.
- "no (mishandles large arguments)", means it works halfway, the
override in lib/nanosleep.c can use the system's nano
Diffutils 3.2 call xfreopen with its first argument NULL, expecting
the underlying reopen to handle this. However, the MS runtime does
not implement the Posix semantics of such a call, and so, for example,
MinGW-compiled cmp fails when invoked to compare its stdin with a
file:
D:\gnu\diffutils-
Bruno Haible wrote:
> This cross-compilation guess is also suboptimal:
>
> checking for d_ino member in directory struct... no
>
> since d_ino is known to work on glibc/Linux since ever:
> glibc/sysdeps/unix/sysv/linux/bits/dirent.h is essentially unchanged since
> 1997.
>
>
> 2012-05-05 Bruno H
Bruno Haible wrote:
> Another suboptimal cross-compilation guess is
>
> checking whether tzset clobbers localtime buffer... yes
>
> This fixes it.
>
>
> 2012-05-05 Bruno Haible
>
> tzset: Avoid guessing wrong when cross-compiling to glibc systems.
> * m4/tzset.m4 (gl_FUNC_TZSET_CLO
Hi Eli,
> Diffutils 3.2 call xfreopen with its first argument NULL, expecting
> the underlying reopen to handle this. However, the MS runtime does
> not implement the Posix semantics of such a call, and so, for example,
> MinGW-compiled cmp fails when invoked to compare its stdin with a
> file:
>
Bruno Haible wrote:
> Another suboptimal cross-compilation guess is
>
> checking for working nanosleep... cross-compiling
>
> This test has 3 possible results:
> - "yes", it works, no override needed.
> - "no (mishandles large arguments)", means it works halfway, the
> override in lib/nan
Jim Meyering wrote:
> This looks fine, modulo a nit in the comment above:
> s/works on when/works when/
Oops, right. Fix applied.
Bruno
When quoting a shell command argument (using shell_quoting_style or
shell_always_quoting_style), quotearg.c uses the '..' style of
quoting. This doesn't work for MinGW, which supports only the ".."
style. This causes, e.g., diff3 to fail for file names with embedded
whitespace or other special ch
> From: Bruno Haible
> Cc: bug-gnu-ut...@gnu.org
> Date: Sat, 05 May 2012 16:26:55 +0200
>
> > Diffutils 3.2 call xfreopen with its first argument NULL, expecting
> > the underlying reopen to handle this. However, the MS runtime does
> > not implement the Posix semantics of such a call, and so,
Hi Niels,
(adding bug-gnulib@)
Am 27.04.2012 um 17:24 schrieb Niels Möller:
> Simon Josefsson writes:
>> Yes. Understanding what the differences is, and which one is right,
>> seems useful first though. If the problem is in gnulib, we can fix
>> that and GnuTLS will have the new variant soon.
>
Eli Zaretskii wrote:
> When quoting a shell command argument (using shell_quoting_style or
> shell_always_quoting_style), quotearg.c uses the '..' style of
> quoting. This doesn't work for MinGW, which supports only the ".."
> style. This causes, e.g., diff3 to fail for file names with embedded
>
> From: Bruno Haible
> Cc: bug-gnu-ut...@gnu.org
> Date: Sat, 05 May 2012 20:08:45 +0200
>
> Eli Zaretskii wrote:
> > When quoting a shell command argument (using shell_quoting_style or
> > shell_always_quoting_style), quotearg.c uses the '..' style of
> > quoting. This doesn't work for MinGW, w
Dagobert Michelsen writes:
> I see different possibilities on how this can be resolved:
>
> 1. nettle uses the gnulib definitions
I currently have no plans to switch to using gnulib.
As far as I'm aware, there's no problem with the types which nettle
actually uses. So it would be a reasonable w
On 05/05/2012 12:19 PM, Niels Möller wrote:
So code which uses the int_fast*_t types and relies on gnulib will get a
slightly different ABI
Generally speaking, it's unwise to use
the int_fast*_t types in a public header file.
This is a documented issue in Gnulib.
It's hard to imagine a general
On 05/05/2012 09:54 AM, Eli Zaretskii wrote:
When quoting a shell command argument (using shell_quoting_style or
shell_always_quoting_style), quotearg.c uses the '..' style of
quoting. This doesn't work for MinGW, which supports only the ".."
style. This causes, e.g., diff3 to fail for file nam
21 matches
Mail list logo
