Paul Eggert wrote:
> On platforms lacking fchdir,
> put a wrapper around 'open' so that we can keep track of which file
> descriptors correspond to directories. The 'open' wrapper puts the
> name of the opened directory into a hash table. (The name must be
> absolute, so 'open' may need to do the
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for working on it, but I think we'd prefer a solution that
> doesn't require the maintainer having to think about obsolete
> platforms that lack fchdir.
>
> How about the following idea instead? On platforms lacking fchdir,
> put a wrapper around 'op
Thanks for working on it, but I think we'd prefer a solution that
doesn't require the maintainer having to think about obsolete
platforms that lack fchdir.
How about the following idea instead? On platforms lacking fchdir,
put a wrapper around 'open' so that we can keep track of which file
descri
Bruno Haible <[EMAIL PROTECTED]> writes:
> Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
>
> stat.c: In function `print_statfs':
> stat.c:416: error: incompatible types in initialization
Thanks for reporting this. Oops, this is another MacOS problem (I got
misled by
Bruno Haible <[EMAIL PROTECTED]> writes:
> Single-stepping with "next" yields a loop in tail.c:
This is because 'tail' is confused again about the distinction between
pipes and sockets. This is a bit of a can of worms (it was the topic
of a discussion on the Open Group a while ago, so I knew abo
Paul Eggert wrote:
> 2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
>
> * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This
> macro was being used without being defined.
Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
stat.c: In function `print_st
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > The reason is that BeOS does not have PF_INET, only AF_INET, but usually
>> > they
>> > have the same values. Also it doesn't have PF_UNSPEC.
>>
>> Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
>> PF_I
Simon Josefsson wrote:
> > The reason is that BeOS does not have PF_INET, only AF_INET, but usually
> > they
> > have the same values. Also it doesn't have PF_UNSPEC.
>
> Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
> PF_INET or PF_UNSPEC? Maybe they are in some non-stan
Btw, the "#ifdef __GLIBC__" in m4/fsusage.m4 looks wrong also for
the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not
appear to access /proc.
/proc doesn't exist on GNU, never did.
Cheers.
Jim Meyering asks:
> I'm curious: what's your motivation for using it?
Portability testing. Through the BeOS porting, I found the following
problems not limited to BeOS:
- check-AUTHORS: applies to any platform that doesn't build all of the
programs.
- mbchar.h problem: applies to any plat
Hi Bruno,
Thanks for all of your recent BeOS porting work.
We've received very few reports about BeOS problems, other than yours.
I'm curious: what's your motivation for using it?
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
> After producing this patch, I noticed that the replacement 'statfs' tha
Bruno Haible <[EMAIL PROTECTED]> writes:
> The 'df' program needs a small adjustment so that the 'struct statvfs' of
> BeOS can be used. And the 'stat' program needs porting too; here the
> 'struct statvfs' cannot be used, because it does not have a f_type
Thanks. While testing this on GNU/Linux
Bruno Haible <[EMAIL PROTECTED]> writes:
> The reason is that BeOS does not have PF_INET, only AF_INET, but usually they
> have the same values. Also it doesn't have PF_UNSPEC.
Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
PF_INET or PF_UNSPEC? Maybe they are in some non-
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/readutmp.m4 (gl_READUTMP): Compile readutmp.c only if or
>exists.
> * lib/readutmp.h: Skip most definitions if neither nor
>exists.
Thanks for the port; I installed that
Paul Eggert wrote:
> Also, we need to define HAVE_FCHMOD when fchmod is available.
Yes, sorry. Coreutils already provides the HAVE_FCHMOD in config.h.in;
I had forgotten that dirchownmod is also in gnulib.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
> ! #if HAVE_FCHMOD
> ! if (0 <= fd)
> ! result = fchmod (fd, chmod_mode);
> ! else
> ! #endif
Thanks for the report and fix. A couple of things: first, I prefer to
avoid #if in C functions when it's easy. Also, we need to
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-18 Bruno Haible <[EMAIL PROTECTED]>
>
> Add support for NetBSD 3.0.
> * m4/ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS): Also check for
> sys/statvfs.h. When getmntinfo was found, check its declaration and
> set either MO
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks; I installed that patch into gnulib too,
Thanks.
> since I'm working on getting coreutils to use gnulib-tool.
Great!
Thanks; I installed that patch into gnulib too, since I'm working on
getting coreutils to use gnulib-tool.
For gnulib readers, here's the just-installed patch:
http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00141.html
Jim Meyering <[EMAIL PROTECTED]> wrote:
> "Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
> ...
>> Tried to compile coreutils 6.0 from alpha.gnu, and here is the result.
> ...
>> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreutils.a
>> ../lib/libcoreutils.a
>> ../lib/libcoreutils.
"Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
...
> Tried to compile coreutils 6.0 from alpha.gnu, and here is the result.
...
> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreutils.a
> ../lib/libcoreutils.a
> ../lib/libcoreutils.a(gettime.o): In function `gettime':
> /home/gzp/sr
21 matches
Mail list logo
