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
While compiling on BeOS, a more difficult problem shows up in the testsuite:
recursive "chown -R ..." and recursive removals "rm -r ..." fail with error
message "Function not implemented" (= strerror(ENOSYS)). The reason:
BeOS doesn't have an fchdir() function, nor fdopendir(), nor a /proc filesys
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
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
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
Hi Simon,
Compiling coreutils-6.0 on BeOS gives this:
source='getaddrinfo.c' object='getaddrinfo.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -DLIBDIR=\"/boot/home/config/lib\" -I. -I. -I.. -I.. -I.
-Wall -I/boot/h
On platforms without or , there is no need for the
read_utmp function (since 'pinky', 'users', 'who' are not built and
uptime.c doesn't call read_utmp with the previous proposed patch). Here are
minimal changes to avoid compilation errors in readutmp.h (still included
by uptime.c) and readutmp.c.
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
Compiling coreutils-6.0 on BeOS, we have this warning:
source='dirchownmod.c' object='dirchownmod.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -DLIBDIR=\"/boot/home/config/lib\" -I. -I. -I.. -I.. -I.
-Wall -I/boot/h
Compiling coreutils-6.0 on BeOS leads to a compilation error:
source='strstr.c' object='strstr.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -DLIBDIR=\"/boot/home/config/lib\" -I. -I. -I.. -I.. -I.
-Wall -I/boot/h
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
Hi,
On NetBSD 3.0/x86, coreutils fail to compile like this:
if gcc -std=gnu99 -DHAVE_CONFIG_H -DLIBDIR=\"/home/bruno/gnu/lib\" -I. -I. -I..
-I.. -I. -I/home/bruno/gnu/include -g -O2 -MT mountlist.o -MD -MP -MF
".deps/mountlist.Tpo" -c -o mountlist.o mountlist.c; then mv -f
".deps/mountlis
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/libcoreu
"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 fun
FYI, I've just released coreutils-6.0.
Here's the announcement:
http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/7725
29 matches
Mail list logo
