Re: fdatasync module proposal

Hi Paul, > Surely coreutils is not the only program that will have problems > with fdatasync on Mac OS. How about the following gnulib patches? > One is for fdatasync, the other for its tests. Looks mostly good. Just small comments: > --- a/lib/unistd.in.h > +++ b/lib/unistd.in.h > @@ -483,6 +4

Re: [PATCH 02/10] test-pselect: new module

Paul Eggert wrote on 2011-07-05: > --- /dev/null > +++ b/tests/test-pselect.c > @@ -0,0 +1,2 @@ > +#define TEST_PSELECT > +#include "test-select.c" > diff --git a/tests/test-select.c b/tests/test-select.c > index 5c15320..9e927f8 100644 > --- a/tests/test-select.c > +++ b/tests/test-select.c > @@

enhance sys_select tests

The FD_* macros/functions are defined by the header file, not by the select() function. Therefore I'm moving their unit tests: 2011-07-22 Bruno Haible sys_select tests: Check the signature of FD_*. * tests/test-select.c (FD_CLR, FD_ISSET, FD_SET, FD_ZERO): Move signat

Re: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.

Paul Eggert wrote: > Recent versions of MacOS seem to have a _DARWIN_C_SOURCE flag that > has roughly the same role that _GNU_SOURCE has for GNU systems. It's not "roughly the same". _GNU_SOURCE makes some symbols visible that are not visible by default. Whereas _DARWIN_C_SOURCE makes some symbols

gnulib.mk & bootstrap confusion

build-aux/bootstrap seems to use gnulib.mk rather than Makefile.am, and further to hardwire this choice. This is what bootstrap-using projects like coreutils seem to use. But I can't find it documented anywhere; am I missing something? If not, a note in the manual might be nice. -- http://rrt.sc3

Re: [PATCH 2/3] large-inode: New module

On 07/22/11 10:45, Pádraig Brady wrote: > If it works it would be better in AC_SYS_LARGEFILE (as well) I think. OK, thanks, I pushed this into gnulib. Assuming it works (and I don't see why it'd hurt) I'll push it into autoconf. >From a7df7c7d3f2f32d0cad31f65505cfee939d91f4a Mon Sep 17 00:00:00

fdatasync module proposal

Surely coreutils is not the only program that will have problems with fdatasync on Mac OS. How about the following gnulib patches? One is for fdatasync, the other for its tests. >From d5c4b4b9266db16c8477a94640290e0b662cee93 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 22 Jul 2011 14:00

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)

On 07/21/11 16:00, Herb Wartens wrote: > I am still seeing the fdatasync > warnings though. I just pushed this patch, which should fix things. Please let me know if it doesn't. Looking around the net, it appears that the fdatasync of Mac OS 10.7 is not effective, so it's better to be safe here an

Re: bug#9140: Coreutils Bug on OSX 10.7 (Lion)

Paul Eggert wrote: > Thanks for the further information about the problem with MacOS X 10.7. > Can you please try this patch? If you don't have autotools installed, > you can edit 'configure' by hand and install a similar patch there. > Thanks. > > I have pushed this into gnulib as it seems pretty

Re: [PATCH 2/3] large-inode: New module

On 22/07/11 18:22, Paul Eggert wrote: > Here's another module I'm adding to coreutils. > I plan to change coreutils to use it. > Another possibility, I suppose, would be to fold it into > AC_SYS_LARGEFILE. > > Herb, can you please try out the effect of this module by > appending "#define _DARWIN_U

Re: bug#9140: Coreutils Bug on OSX 10.7 (Lion)

Thanks for the further information about the problem with MacOS X 10.7. Can you please try this patch? If you don't have autotools installed, you can edit 'configure' by hand and install a similar patch there. Thanks. I have pushed this into gnulib as it seems pretty simple. The basic idea is to

[PATCH 2/3] large-inode: New module

Here's another module I'm adding to coreutils. I plan to change coreutils to use it. Another possibility, I suppose, would be to fold it into AC_SYS_LARGEFILE. Herb, can you please try out the effect of this module by appending "#define _DARWIN_USE_64_BIT_INODE 1" to lib/config.h after running 'co

[PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.

Recent versions of MacOS seem to have a _DARWIN_C_SOURCE flag that has roughly the same role that _GNU_SOURCE has for GNU systems. I pushed the following patch into gnulib, under the theory that it is more in the line with the usual Autoconf / gnulib philosophy, and it may fix some porting issues.

Re: [PATCH] file-has-acl: use acl_extended_file_nofollow() if available

Kamil Dudka wrote: > On Wednesday 06 April 2011 16:49:31 Kamil Dudka wrote: >> the attached patch allows ls(1) from coreutils to eliminate unnecessary >> calls of getxattr() and thus prevents it from triggerring unnecessary >> mounts while listing files. The feature is enabled automatically whenev

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

On 07/21/11 23:14, Eli Zaretskii wrote: > I'm sure recovering 3 minutes of needless compilation will > be quite a win, at a cost of a couple of additional recipes If the only cost were two small make rules, that would indeed be a win. I worry the cost will be larger than that. But please feel fre