Re: coreutils-6.0 on platforms without fchdir

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

Re: coreutils-6.0 on platforms without fchdir

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

Re: coreutils-6.0 on platforms without fchdir

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

coreutils-6.0 on BeOS (10)

yield numbers 3, 4, 5, ...) 2006-08-20 Bruno Haible <[EMAIL PROTECTED]> * src/remove.c (remove_cwd_entries): Disable assertion on BeOS. --- coreutils-6.0-beos/src/remove.c 2006-08-20 16:00:08.0 +0200 +++ coreutils-6.0-beos/src/remove.c 2006-08-20 18:08:58.0

coreutils-6.0 on platforms without fchdir

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

Re: coreutils-6.0 on BeOS (9)

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

Re: coreutils-6.0: numerous test failures on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > The process that hangs has the command line "tail -f -n 1". I installed the following patch to coreutils in an attempt to fix this. It uses the new isapipe module of gnulib. I think this finishes off the MacOS X problems you've reported recently. 2006

Re: coreutils-6.0: numerous test failures on MacOS X

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

Re: coreutils-6.0: numerous test failures on MacOS X

I installed this patch to coreutils to address the O_DIRECTORY problem; it assumes the new gnulib fcntl module. 2006-08-28 Paul Eggert <[EMAIL PROTECTED]> Adjust to recent gnulib changes for the gnulib module. * bootstrap.conf (gnulib_modules): Add fcntl. * src/system.h

Re: coreutils-6.0 on BeOS (9)

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

Re: coreutils-6.0 on BeOS (6)

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

Re: coreutils-6.0 on BeOS (6)

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

Re: coreutils-6.0: numerous test failures on MacOS X

> > + dd iflag=nofollow if=dd-sym.20477 count=0 > > + fail=1 > > ... > > It seems that the nofollow test doesn't work? > > What does ktrace tell you about the system calls that were executed? > I assume MacOS X has ktrace? > > cd src > ln -s dd.c sym > ktrace ./dd iflag=nofollow if=sym coun

Re: coreutils-6.0 on BeOS (9)

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

Re: coreutils-6.0 on BeOS (9)

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

Re: coreutils-6.0 on BeOS (9)

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

Re: coreutils-6.0 on BeOS (8)

Bruno Haible <[EMAIL PROTECTED]> writes: > 2006-08-19 Bruno Haible <[EMAIL PROTECTED]> > > BeOS portability. > * src/ls.c (SA_RESTART): Fallback define. Thanks, I installed that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http:

Re: coreutils-6.0 on BeOS (7)

Bruno Haible <[EMAIL PROTECTED]> writes: > BeOS has no quotas and no EDQUOT. Fortunately it is easy to fix. Thanks. I installed the following slightly-different fix, since we tend to put those defns in system.h. 2006-08-23 Paul Eggert <[EMAIL PROTECTED]> * src/system.h (EDQUOT): Defi

Re: coreutils-6.0 on BeOS (9)

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. ___ Bug-coreutils mailing list Bug-coreutil

coreutils-6.0 on BeOS (9)

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

coreutils-6.0 on BeOS (8)

On BeOS, compilation fails like this: source='ls.c' object='ls.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -Wall -I/boot/home/config/include -g -O2 -c ls.c /boot/home/gnubuild/coreut

coreutils-6.0 on BeOS (7)

On BeOS, compilation fails like this: source='ln.c' object='ln.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -Wall -I/boot/home/config/include -g -O2 -c ln.c /boot/home/gnubuild/coreut

Re: coreutils-6.0 on BeOS (6)

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-

Re: coreutils-6.0 on BeOS (4)

Bruno Haible <[EMAIL PROTECTED]> writes: > 2006-08-19 Bruno Haible <[EMAIL PROTECTED]> > > BeOS portability. > * m4/boottime.m4 (GNULIB_BOOT_TIME): Test also for utmp.h, utmpx.h, > OS.h. Don't require to have utmp.h or utmpx.h. Enable boottime > support if is found. >

Re: coreutils-6.0 on BeOS (5)

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

coreutils-6.0 on BeOS (6)

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

coreutils-6.0 on BeOS (5)

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.

coreutils-6.0 on BeOS (4)

On BeOS, coreutils wouldn't install the 'uptime' program. But BeOS has a system call that returns the boot time. This makes it possible to port the 'uptime' program. 2006-08-19 Bruno Haible <[EMAIL PROTECTED]> BeOS portability. * m4/boottime.m4 (GNULIB_BOOT_TIME): Test also for

Re: coreutils-6.0 on BeOS (3)

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 ___ Bug-coreutils mailing list Bug-core

Re: coreutils-6.0 on BeOS (1)

Bruno Haible <[EMAIL PROTECTED]> wrote: > On BeOS 5, building coreutils shows, apart from the c89-c99 and the gzip > --help > issue (which have already been handled), a number of minor compilation > failures. ... > a "make check" attempts to builds the programs > chroot - and fails because BeOS

Re: coreutils-6.0 on BeOS (3)

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

coreutils-6.0 on BeOS (3)

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

coreutils-6.0 on BeOS (1)

Hi, On BeOS 5, building coreutils shows, apart from the c89-c99 and the gzip --help issue (which have already been handled), a number of minor compilation failures. The first problem is that, although src/Makefile has EXTRA_PROGRAMS = chroot$(EXEEXT) df$(EXEEXT) hostid$(EXEEXT) \ nic

Re: coreutils-6.0: compilation failure on NetBSD 3.0 (2)

[EMAIL PROTECTED] (Eric Blake) writes: > 2006-08-20 Eric Blake <[EMAIL PROTECTED]> > > * src/stat.c (USE_STATVFS): Reinstate the patch from 2006-08-15; > the patch from 2006-08-18 broke on cygwin. Thanks for checking it; I installed that. __

Re: coreutils-6.0: compilation failure on NetBSD 3.0 (2)

> > Thanks for this patch; I installed it into both gnulib and coreutils. > > Eric, this seems to supersede the Cygwin-related patch > that I > installed into CVS coreutils recently (revision 1.95, date: 2006-08-15 > 16:23:28 -0700), s

Re: coreutils-6.0: compilation failure on NetBSD 3.0 (1)

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

Re: coreutils-6.0: compilation failure on NetBSD 3.0 (2)

Bruno Haible <[EMAIL PROTECTED]> writes: > 2006-08-18 Bruno Haible <[EMAIL PROTECTED]> > > Add support for NetBSD 3.0. > * m4/stat-prog.m4 (cu_PREREQ_STAT_PROG): Test also for f_fstypename > in struct statvfs. > * src/stat.c (USE_STATVFS): Set to 1 if 'struct statvfs' has

coreutils-6.0: compilation failure on NetBSD 3.0 (2)

Hi, On NetBSD 3.0/x86, coreutils fail to compile like this: if gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -Wall -I/home/bruno/gnu/include -g -O2 -MT stat.o -MD -MP -MF ".deps/stat.Tpo" -c -o stat.o stat.c; then mv -f ".deps/stat.Tpo" ".deps/stat.Po"; else rm -f

coreutils-6.0: compilation failure on NetBSD 3.0 (1)

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

Re: coreutils 6.0

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

Re: coreutils 6.0

"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

Re: coreutils 6.0: ls --time-style=locale broken

Andreas Schwab <[EMAIL PROTECTED]> writes: > ls uses the ugly iso format even if --time-style=locale (or > TIME_STYLE=locale). Please ignore this, I was missing some locale files. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg

coreutils 6.0: ls --time-style=locale broken

ls uses the ugly iso format even if --time-style=locale (or TIME_STYLE=locale). $ locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC=en_US.UTF-8 LC_TIME="de_DE.UTF-8" LC_COLLATE=C LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=en_US.UTF-8 LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_D

Re: coreutils 6.0: ls -CF output misaligned

Andreas Schwab <[EMAIL PROTECTED]> wrote: > length_of_file_name_and_frills mishandles entries that have never been > passed to stat. This causes the output of ls -CF to be misaligned. > > $ /bin/ls -CF > afros/ dejagnu/gnus/ pack-dejagnu* qemu/ > alsa-kernel/ diffutils/

coreutils 6.0: ls -CF output misaligned

length_of_file_name_and_frills mishandles entries that have never been passed to stat. This causes the output of ls -CF to be misaligned. $ /bin/ls -CF afros/ dejagnu/gnus/ pack-dejagnu* qemu/ alsa-kernel/ diffutils/ grep/ pack-emacs*sharutils/ aranym/

FYI, coreutils-6.1 coming soon [Re: coreutils-6.0 released

> Coreutils version 6.0 has been released. I'm planning to release coreutils 6.1 soon (but not before Saturday), so if any of you can do further testing, please do it sooner, and report any problems. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org

Re: coreutils-6.0: compilation failure with c89 compiler

Bruno Haible <[EMAIL PROTECTED]> wrote: > The c99-to-c89.diff mentioned in the announcement is not enough to > build with Solaris cc on Solaris 7. I get an error Hi Bruno, Thanks for reporting all of these. > source='fts.c' object='fts.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../bui

Re: coreutils-6.0: numerous test failures on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > After this is fixed, only dd/misc fails, and tail/tail-tests hangs. Thanks. Your email didn't mention tail/tail-tests after that -- is that problem known and fixed, or should we look into it further? > + dd iflag=nofollow if=dd-sym.20477 count=0 > + fa

Re: coreutils-6.0: test failures on Solaris 7

Bruno Haible <[EMAIL PROTECTED]> writes: > On Solaris 7, building with "cc -O", I get two test failures: Thanks for reporting these. I installed the following, which I hope fixes them. I'd like tests/ls-2/tests to skip only the setuid-etc test if its setup can't be done, but I don't see any eas

Re: coreutils-6.0: numerous test failures on MacOS X

Paul Eggert wrote: > I think this is the right sort of fix, though I'm puzzled as to why > the code set LC_ALL to the empty string in the first place. > ... > Do you recall why they were set to '' back then? Yes, my archives tell me: On 2000-10-15, I sent Jim a mail, reporting testsuite failures,

Re: coreutils-6.0: numerous test failures on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > 2006-08-16 Bruno Haible <[EMAIL PROTECTED]> > > * tests/lang-default: Set LC_ALL to "C", not empty. I think this is the right sort of fix, though I'm puzzled as to why the code set LC_ALL to the empty string in the first place. This dates back t

Re: [PATCH] coreutils-6.0 memcoll fix

Pádraig Brady <[EMAIL PROTECTED]> writes: > The following obvious patch is needed for the memcoll change in 6.0. Thanks, I applied it. Eric Blake <[EMAIL PROTECTED]> writes: > I guess we did document in memcoll.c that memcoll explicitly sets > errno to 0 on success, making memcoll not quite lik

coreutils-6.0: test failures on Solaris 7

Hi, On Solaris 7, building with "cc -O", I get two test failures: chmod/setgid fails Here are details: $ VERBOSE=yes gmake check TESTS=setgid gmake check-TESTS gmake[1]: Entering directory `/opt/coreutils-6.0/t

Re: coreutils 6.0

On Wed, Aug 16, 2006 at 11:38:28AM +0200, Jim Meyering wrote: Ok. Then I'll use a more robust test for file system type. This also relaxes the test to run if "." is an ext2 file system. Does this patch solve the problem? looks like it Mike Stone _

coreutils-6.0: compilation failure with c89 compiler

Hi, The c99-to-c89.diff mentioned in the announcement is not enough to build with Solaris cc on Solaris 7. I get an error source='fts.c' object='fts.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \ cc -O -DHAVE_CONFIG_H -DLIBDIR=\"/nfs/visu/telecom/users/haible/gnu/arch

Re: coreutils-6.0: "make" output on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: > The problem is the gzip call in Makefile.maint. "make" is GNU make 3.79. > "gzip" is 1.2.4, and it prints --help output to stderr. > > The appended patch fixes the problem. > > Bruno > > > 2006-08-16 Bruno Haible <[EMAIL PROTECTED]> > > * Makefile.m

Re: [PATCH] coreutils-6.0 memcoll fix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 8/16/2006 2:50 AM: > +++ memcoll-errno.c 2006-08-16 06:50:28.0 + > @@ -43,7 +43,10 @@ > the buffers using strcoll on each substring. */ > >if (s1len == s2len && memcmp (s1, s2, s1len) == 0) > -

Re: coreutils-6.0: two testsuite problems on Linux/x86

Bruno Haible <[EMAIL PROTECTED]> wrote: > On Linux/x86 (Linux 2.4.21, glibc-2.3.6) I get: > > make[3]: Entering directory `/build/coreutils-6.0/tests/dd' > dd iflag=noatime updated atime; O_NOATIME bug in your kernel? > FAIL: misc > > Your announcement says tha

coreutils-6.0: "make" output on MacOS X

Building coreutils-6.0 on MacOS X 10.3.9 (Darwin 7.9): configure runs fine; then $ make gzip 1.2.4 (18 Aug 93) usage: gzip [-cdfhlLnNrtvV19] [-S suffix] [file ...] -c --stdout write on standard output, keep original files unchanged -d --decompress decompress -f --force force

coreutils-6.0: two testsuite problems on Linux/x86

On Linux/x86 (Linux 2.4.21, glibc-2.3.6) I get: make[3]: Entering directory `/build/coreutils-6.0/tests/dd' dd iflag=noatime updated atime; O_NOATIME bug in your kernel? FAIL: misc Your announcement says that O_NOATIME is only supported in Linux >= 2.6.8. So this should be an XFAIL, no

Re: coreutils 6.0: fix portability problem in acl test

Andreas Schwab <[EMAIL PROTECTED]> wrote: > The == operator is not a portable test operator, it should be = instead. > > 2006-08-16 Andreas Schwab <[EMAIL PROTECTED]> > > * tests/cp/acl: Don't use non-portable == operator for test. Applied. Thanks. __

coreutils 6.0: fix portability problem in acl test

The == operator is not a portable test operator, it should be = instead. Andreas. 2006-08-16 Andreas Schwab <[EMAIL PROTECTED]> * tests/cp/acl: Don't use non-portable == operator for test. --- tests/cp/acl.~1.5.~ 2005-11-17 22:17:35.0 +0100 +++ tests/cp/acl2006-08-16 1

Re: coreutils 6.0

Michael Stone <[EMAIL PROTECTED]> wrote: > On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote: >>What version of Linux is that? > > 2.6.17 > >>From the name of the directory, it's probably a tmpfs file system. > > actually it's xfs. it's inside a pbuilder chroot, so the mtab is going > t

Re: coreutils 6.0

On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote: What version of Linux is that? 2.6.17 From the name of the directory, it's probably a tmpfs file system. actually it's xfs. it's inside a pbuilder chroot, so the mtab is going to be completely bogus (I think mount would report /

Re: coreutils 6.0, Solaris 9 build failure

On Tue 06-08-15 22:12, Paul Eggert wrote: > Keith Thompson <[EMAIL PROTECTED]> writes: > > > I got the same error with gcc 4.1.1. > > Are you building GCC with the Sun linker, or with the binutils linker? > I'm doing the former, and that might be related to the problem. Not > that I think it mat

[PATCH] coreutils-6.0 memcoll fix

Sorry Paul. The following obvious patch is needed for the memcoll change in 6.0. I didn't notice it in my quick test as I had forgotten I changed xmemcoll to memcoll in uniq in my tree. I only noticed errno being non zero for me when I redirect uniq to >/dev/null but I guess there are a million o

Re: coreutils 6.0

Michael Stone <[EMAIL PROTECTED]> wrote: > test failure: > > /usr/bin/make check-TESTS > make[4]: Entering directory > `/tmp/buildd/coreutils-6.0/build-tree/coreutils-6.0/tests/ls' > PASS: stat-failed > ls: cannot access d/s: Permission denied > out exp

Re: coreutils 6.0, Solaris 9 build failure

Keith Thompson <[EMAIL PROTECTED]> writes: > I got the same error with gcc 4.1.1. Are you building GCC with the Sun linker, or with the binutils linker? I'm doing the former, and that might be related to the problem. Not that I think it matters, but I built GCC 4.1.1 with "CONFIG_SHELL=/bin/ksh

Re: coreutils 6.0, Solaris 9 build failure

I've also run into a build problem on Solaris 7; details to follow. -- Keith Thompson (The_Other_Keith) [EMAIL PROTECTED] San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this.

Re: coreutils 6.0, Solaris 9 build failure

On Tue 06-08-15 16:50, Paul Eggert wrote: > Keith Thompson <[EMAIL PROTECTED]> writes: > > > There's also a gcc 4.1.1 on the system. I'll try again with that. > > Thanks. I got the same error with gcc 4.1.1. > You might also want to try with /opt/sfw/bin/gcc. > (It's GCC 2.95.3, which should b

Re: coreutils 6.0, Solaris 9 build failure

Keith Thompson <[EMAIL PROTECTED]> writes: > There's also a gcc 4.1.1 on the system. I'll try again with that. Thanks. You might also want to try with /opt/sfw/bin/gcc. (It's GCC 2.95.3, which should be entertaining. :-) ___ Bug-coreutils mailing l

Re: coreutils 6.0, Solaris 9 build failure

On Tue 06-08-15 15:30, Paul Eggert wrote: > Keith Thompson <[EMAIL PROTECTED]> writes: > > > % uname -a > > SunOS elmak 5.9 Generic_118558-20 sun4u sparc SUNW,Sun-Blade-100 Solaris > > % config.guess > > sparc-sun-solaris2.9 > > % gcc --version > > gcc (GCC) 4.0.2 > > [...] > > > > The build fail

Re: coreutils 6.0, cygwin build failure

Eric Blake <[EMAIL PROTECTED]> writes: > I've known about it and patched it in my local tree since April, but my patch > in savannah was unfortunately never applied: > > http://savannah.gnu.org/bugs/?func=detailitem&item_id=16325 Thanks for mentioning that. I don't fully understand the issues h

Re: coreutils 6.0, Solaris 9 build failure

Keith Thompson <[EMAIL PROTECTED]> writes: > % uname -a > SunOS elmak 5.9 Generic_118558-20 sun4u sparc SUNW,Sun-Blade-100 Solaris > % config.guess > sparc-sun-solaris2.9 > % gcc --version > gcc (GCC) 4.0.2 > [...] > > The build fails with the following error message: > > gai_strerror.c:70: error

coreutils 6.0, cygwin build failure

On cygwin: if gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib - I/usr/local/include -g -O2 -MT stat.o -MD -MP -MF ".deps/stat.Tpo" -c -o stat.o stat.c; \ then mv -f ".deps/stat.Tpo" ".deps/stat.Po"; else rm - f ".deps/stat.Tpo"; exit 1; fi stat.c: In function `hum

coreutils 6.0, Solaris 9 build failure

% uname -a SunOS elmak 5.9 Generic_118558-20 sun4u sparc SUNW,Sun-Blade-100 Solaris % config.guess sparc-sun-solaris2.9 % gcc --version gcc (GCC) 4.0.2 [...] The build fails with the following error message: gai_strerror.c:70: error: conflicting types for 'gai_strerror' /usr/include/netdb.h:311:

coreutils-6.0 released

5.93 through 5.97. I hope to make no more releases from that branch. Coreutils 6.0 is the first release off the trunk since 5.92, and considering the number and scope of the changes, I've labeled it "unstable". However, many of the changes have been for improved robustness and p