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
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
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
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
or f_fstypename or similar field.
Btw, the "#ifdef __GLIBC__" in m4/fsusage.m4 looks wro
