Hi Eric, and thanks for the quick patch.
On Wednesday 27 July 2011, Eric Blake wrote:
> Make sure we don't unintentionally revert this intentional break
> in the typical autoconf style because a future change was only
> tested with newer autoconf.
>
> * m4/absolute-header.m4: Document AS_VAR_PUSH
Make sure we don't unintentionally revert this intentional break
in the typical autoconf style because a future change was only
tested with newer autoconf.
* m4/absolute-header.m4: Document AS_VAR_PUSHDEF limitation.
* m4/include_next.m4: Likewise.
* m4/warn-on-use.m4: Likewise.
* m4/warnings.m4:
On 07/26/2011 02:23 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
Hi Eric. Hope you don't mind hearing a minor nit ...
...
- AS_VAR_SET([gl_next_header], ['<'gl_HEADER_NAME'>'])
+ AS_VAR_SET(gl_next_header, ['<'gl_HEADER_NAME'>'])
IMHO you should add a comment here explaining
Paolo Bonzini wrote:
> On 07/26/2011 03:42 PM, Jim Meyering wrote:
>> I don't know about typical mingw file system usage.
>> Do mingw users use NTFS often?
>
> Yes, all of them. MinGW is just the name of the free compiler
> toolchain for Windows. Unlike cygwin, it uses the MS C library, so
> any
Stefano Lattarini wrote:
> Hi Eric. Hope you don't mind hearing a minor nit ...
...
>> - AS_VAR_SET([gl_next_header], ['<'gl_HEADER_NAME'>'])
>> + AS_VAR_SET(gl_next_header, ['<'gl_HEADER_NAME'>'])
>>
> IMHO you should add a comment here explaining why you are underquoting
> (and thus
Hi Eric. Hope you don't mind hearing a minor nit ...
On Tuesday 26 July 2011, Eric Blake wrote:
> Older autoconf did not know how to peer through quoting of the
> m4 macro created by AS_VAR_PUSHDEF; while newer autoconf has
> been patched to allow typical autoconf quoting rules to still
> apply,
Older autoconf did not know how to peer through quoting of the
m4 macro created by AS_VAR_PUSHDEF; while newer autoconf has
been patched to allow typical autoconf quoting rules to still
apply, compatibility with autoconf 2.59 requires the unquoted
use of the macro name for all uses prior to AS_VAR_
On 07/26/2011 10:05 AM, Eric Blake wrote:
On 07/26/2011 04:45 AM, Daniel P. Berrange wrote:
I was wondering why I didn't see any compile warnings from the broken
gnutls code on RHEL5 when I noticed that we were building without any
compiler warning flags at all.
It seems configure fails on RHEL
On 07/26/2011 03:42 PM, Jim Meyering wrote:
I don't know about typical mingw file system usage.
Do mingw users use NTFS often?
Yes, all of them. MinGW is just the name of the free compiler toolchain
for Windows. Unlike cygwin, it uses the MS C library, so anything MS
documents applies to mi
On 07/26/2011 07:50 AM, Santiago Vila wrote:
Yes, most likely this is a kernel and/or glibc bug. POSIX requires
readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
AT_FDCWD or open on a directory. Which does strace say about the
syscall made just before the gnulib test-readlink
B1;2403;0cOn Mon, 20 Jun 2011, Eric Blake wrote:
> > For the record, this is what "git bisect" says:
> >
> > 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> >
> > commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> > Author: Al Viro
> > Date: Sun Mar 13 15:56:26 2011 -0400
>
Paolo Bonzini wrote:
> On 07/26/2011 12:18 PM, Jim Meyering wrote:
>> Regarding NTFS, can you point to a real gnulib-using application that is
>> misbehaving because of this? I've seen that some NTFS implementations
>> *do* have usable inode support. Both cygwin and fuse-based ones do,
>> so you
On 07/26/2011 12:18 PM, Jim Meyering wrote:
Regarding NTFS, can you point to a real gnulib-using application that is
misbehaving because of this? I've seen that some NTFS implementations
*do* have usable inode support. Both cygwin and fuse-based ones do,
so you must mean mingw.
Yes, I mean m
Paolo Bonzini wrote:
> On 07/24/2011 09:06 PM, Jim Meyering wrote:
>>> > What about a few POSIX-violating fringe operating systems (Windows and
>>> > DJGPP come to mind)?:) For Windows we can write our own stat
>>> > function in cygwin, but for DJGPP I think we're in a bad situation...
>> AFAI
14 matches
Mail list logo
