Hi Jim,
> You mean you've found *another* problem with GNU rm?
> Is so, please provide details.
The second bug is harder to reproduce.
I have a big tar file with hard links in it.
$ tar tvf cross-hppa.tar | grep ' link '
hrwxr-xr-x bruno/user0 2002-06-02 01:20:05
cross/hppa-linux-tools/
Jim Meyering wrote:
> > The above makes me think your tools have incomplete "weak_alias" support,
> > so that lib/strndup.o ends up with a definition for a function
> > named __strndup, rather than rpl_strndup.
Huh? 'weak_alias' should never be defined, except inside glibc (i.e. if
_LIBC).
> No o
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> Is there any type of file system where readdir works?
>
> Yes. It does work on vfat file systems. No readdir bug reproducible there.
Thanks for checking.
>> What version of Darwin are you using?
>
> Darwin 7.9.0 = MacOS X 10.3.9.
>
> I wro
Hello Jim,
> Is there any type of file system where readdir works?
Yes. It does work on vfat file systems. No readdir bug reproducible there.
> What version of Darwin are you using?
Darwin 7.9.0 = MacOS X 10.3.9.
I wrote:
> In the run test, you can use /bin/rm, since /bin/rm has the same bug
>
p.o): In function `xstrndup':
>> /home/gzp/src/coreutils-6.2/lib/xstrndup.c:37: undefined reference to
>> `rpl_strndup'
>> collect2: ld returned 1 exit status
>> make[2]: *** [cp] Error 1
>> make[2]: Leaving directory `/home/gzp/src/coreutils-6.2/src'
>> m
Jim,
> Is there any type of file system where readdir works?
I tried only HFS+ mounts (on two different volumes).
> What version of Darwin are you using?
Darwin 7.9.0 = MacOS X 10.3.9.
> I see no failure with Darwin-8.7.0, so I might
> add a run-test (like coreutils' old readdir.m4),
> if it's
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I'll use 180.
>> The lower we go, the more of a performance penalty
>> we impose for directories with very many entries.
>
> I tried the value 180. It worked fine in some cases, but still failed in
> others:
Bruno,
Is there any type
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> I'll use 180.
>>> The lower we go, the more of a performance penalty
>>> we impose for directories with very many entries.
>>
>> I tried the value 180. It worked fine in some cases, but stil
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I'll use 180.
>> The lower we go, the more of a performance penalty
>> we impose for directories with very many entries.
>
> I tried the value 180. It worked fine in some cases, but still failed in
> others:
...
> Thus, instead of tes
Jim Meyering wrote:
> I'll use 180.
> The lower we go, the more of a performance penalty
> we impose for directories with very many entries.
I tried the value 180. It worked fine in some cases, but still failed in
others:
$ tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz
$ ll cross/
* Jim Meyering <[EMAIL PROTECTED]>:
| > gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o
../lib/libcoreutils.a ../lib/libcoreutils.a
| > ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup':
| > /home/gzp/src/coreutils-6.2/lib/xstrndup.c:37: un
(Unison won't let me attach a file to a message, nor will it let an
upload come with a message, too lazy to switch to Thoth right now
;) so I'll do this via e-mail)
I cvs update'd within the last half-hour. Builds seem to go fine.
I ran make -k check with all the RUN*TESTS enabled I could di
"Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
...
> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o
> ../lib/libcoreutils.a ../lib/libcoreutils.a
> ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup':
> /home/gzp/src/coreutils-6.2/lib/xstr
<[EMAIL PROTECTED]> writes:
> On 2006-09-26 17:47:51 -0500, Jim Meyering <[EMAIL PROTECTED]> said:
>> Probably because you're not using a new enough version of bison.
>
> Got bison-2.3a from the alpha repo,
2.3a should work as far as I know, but you shouldn't need 2.3a; 2.3
will do.
> Apple inst
<[EMAIL PROTECTED]> wrote:
> On 2006-09-26 17:04:24 -0500, <[EMAIL PROTECTED]> said:
>
>> On 2006-09-25 17:25:01 -0500, <[EMAIL PROTECTED]> said:
>>
>>> I will pull coreutils and gnulib from CVS also and report back.
>> Okay I got a fresh clean copy of coreutils+gnulib, ran ./bootstrap,
>> complai
<[EMAIL PROTECTED]> wrote:
> On 2006-09-25 17:25:01 -0500, <[EMAIL PROTECTED]> said:
>
>> I will pull coreutils and gnulib from CVS also and report back.
>
> Okay I got a fresh clean copy of coreutils+gnulib, ran ./bootstrap,
> complained only a tiny bit about the hu language (smth about 2 or more
mwoehlke <[EMAIL PROTECTED]> wrote:
> Have you considered making this conditional to broken Darwin versions? :-)
Yes. For a long time, there was an autoconf-run-test
to determine the limit, but that is insufficient, since it's
hard to test all file systems that are available at build time,
and im
mwoehlke <[EMAIL PROTECTED]> wrote:
>> Would you please try this, to confirm the theory:
>> #!/bin/bash
>> for i in $(seq 150 200); do
>> echo i=$i
>> mkdir b; (cd b; mkdir $(seq $i) ); Rm -r b || { echo bug at i=$i; break; }
>> done
>> That should find the minimum number of entries for which r
Jim Meyering wrote:
mwoehlke <[EMAIL PROTECTED]> wrote:
...
Did you try with 5.97? I haven't tried 6.2 yet (will try to do that
No, since rm in that release is so different, and since
I don't plan to make a 5.98 release.
soon)... Um, actually, I am probably not going to try until someone can
mwoehlke <[EMAIL PROTECTED]> wrote:
> $ uname -srvmpio
> Darwin 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006;
> root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386 iMac4,1 Darwin
>
> Ah, but it's also a much newer Darwin... so...
>
>> I'm working on building test output (including ver
mwoehlke <[EMAIL PROTECTED]> wrote:
...
> Did you try with 5.97? I haven't tried 6.2 yet (will try to do that
No, since rm in that release is so different, and since
I don't plan to make a 5.98 release.
> soon)... Um, actually, I am probably not going to try until someone can
> tell me how the *&
ges, I think bash was one),
>>> to remove the directory, I have to 'rm -rf coreutils-5.97' as many as
>>> four times before it fully goes away. Odd that just doing it several
>>> times in succession works, though.
>> Now, *that* is interesting.
>>
ay. Odd that just doing it several
> times in succession works, though.
Now, *that* is interesting.
Would you please see if you can reproduce that using an rm binary
built from coreutils-6.2? I couldn't, when using an hfs partition
on Darwin 8.7.0. The core of rm was seriously revamped between
coreutils-5.97 and 6.0.
[EMAIL PROTECTED] wrote:
[let me see if gmane lets me reply to posts]
gmane works great, it's the only way I read this list (and several
others). :-)
btw, thanks for the mails... I just built coreutils on Darwin also, and
had a good number of 'make check' failures. I am also noticing that
this list. Or I think I can access and post via
news.gmane.org with regular newsreaders.)
I built coreutils-6.2 on Darwin-8.7.0 ("Tiger" 10.4.7 and the
latest XCode-2.4). I actually have installed coreutils-5.97 to
compare with.
5.97 seems to work fine, but 6.2 seems to have many thin
<[EMAIL PROTECTED]> wrote:
> I am new to this list, but not at all new to building and using
> open source projects. (Please CC me if needed as I haven't yet
> joined this list. Or I think I can access and post via
> news.gmane.org with regular newsreaders.)
>
> I
26 matches
Mail list logo
