Re: gnulib broken on systems lacking fchdir

Eric Blake wrote:
> Matthew Woehlke writes:
>> That sounds like a good idea, but... does that mean I have to *write* an 
>> entire unistd.h *and* make it work everywhere, or is there a way to 
>> 'drop in' one that pulls the system unistd.h, plus extras?
> 
> For an example of how to provide a replacement <unistd.h>, see how gnulib 
> already provides a replacement <sys/stat.h> which pulls in the system version, 
> then touches it up as needed.  You would really be writing lib/unistd_.h, which 
> first includes  <at> ABSOLUTE_UNISTD_H <at> , then, if HAVE_FCHDIR is not defined, 
> replaces fchdir with rpl_fchdir, etc.

Thanks for the info. Actually, I found unistd_safer.h too, which might 
help? 

>> As mentioned, so far this has nothing to do with coreutils except that I 
>> know it *will* affect coreutils. Right now I'm worrying about gzip.  
>> But... I'm also planning on building gettext (albeit not a version that 
>> has the newer *at stuff AFAIK).
> 
> To my knowledge, gettext does not depend on fchdir (as evidenced by the fact 
> that it builds on mingw).  But coreutils, findutils, tar, and gzip all use 
> gnulib directory traversal.

Ok, but I may try to avoid GPL dependencies anyway.

>> Back to the technical standpoint, come to think of it don't most systems 
>> limit # of fd's to a reasonable number like 1024? 
> 
> No, the GNU spirit is to avoid arbitrary limits, and 1024 is arbitrary