On 11/07/18 10:05, Paul Eggert wrote:
> Thomas Deutschmann wrote:
>
>> Not sure if this is a kernel problem. Isn't test suite using
>> LD_PRELOAD to pull in additional libraries which could cause
>> such a breakage?
>
> You're right, it could be a library problem. The test suite's LD_PRELOAD
> library
> just returns what the C library gives it, though. Perhaps LD_PRELOAD usage is
> messing up malloc on your platform, so that it returns improperly-aligned
> pointers? You might try something like the attached patch to see whether the
> C
> library is doing that.
>
>> And wouldn't "rm" show any failure during normal use?
>
> Yes, one would think so.
>
> In any case, this is not sounding like a bug in coreutils itself.
This could be due to my hack for 32 bit in:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.25-43-g54c1397
which fails due to the alignment requirement on sparc
This is using a 32 bit userland right?
We can skip this test on 32 bit, as there really
is nothing arch specific that we're testing here.
Does this skip the test for you?
diff --git a/tests/rm/rm-readdir-fail.sh b/tests/rm/rm-readdir-fail.sh
index 75fa339..580d8ec 100755
--- a/tests/rm/rm-readdir-fail.sh
+++ b/tests/rm/rm-readdir-fail.sh
@@ -27,9 +27,9 @@ mkdir -p dir/notempty || framework_failure_
cat > k.c <<\EOF || framework_failure_
#define _GNU_SOURCE
-/* Setup so we don't have to worry about readdir64. */
+/* Avoid having to also handle readdir64. */
#ifndef __LP64__
-# define _FILE_OFFSET_BITS 64
+# error skipping test on 32 bit
#endif
#include