FAIL: test-rwlock1 on 32-bit ARM

[Eric Blake]

Adding gnulib, since test-rwlock1 is maintained by gnulib.

Hi Everyone,
I'm building coreutils 8.29 on a CubieTruck v5. The CubieTruck uses a
$ lsb_release -a
No LSB modules are available.
Distributor ID: Linaro
Description: Linaro 14.04
Release: 14.04
Codename: trusty
$ gcc --version
gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2
...
PASS: test-locale
PASS: test-localeconv
PASS: test-localename
FAIL: test-rwlock1
PASS: test-lock
PASS: test-lseek.sh
PASS: test-lstat
...
FAIL: test-rwlock1
==================
Unexpected outcome 3
FAIL test-rwlock1 (exit status: 134)
Any ideas what I might be doing wrong?
Thanks in advance.

[Bruno Haible]

Hi,

FAIL: test-rwlock1
==================
Unexpected outcome 3
FAIL test-rwlock1 (exit status: 134)
Any ideas what I might be doing wrong?

"Unexpected outcome 3" means that the test program could not create a second
thread (other than the main thread). You haven't showed the configure options
and GCC options that you passed; I would guess that they contain an option
that is incompatible to multithreading. Maybe "-static" or something like that?
If so, consider it a normal, expected failure.

Bruno

[Bruno Haible]

PKGCONFIG: /usr/local/lib/pkgconfig
CPPFLAGS: -I/usr/local/include -DNDEBUG
CFLAGS: -g2 -O2 -march=native -fPIC
CXXFLAGS: -g2 -O2 -march=native -fPIC
LDFLAGS: -L/usr/local/lib -Wl,-R,/usr/local/lib -Wl,--enable-new-dtags
LIBS: -ldl -lpthread

Good. This is a supported set of options. (And you are one of the few people
who use /usr/local correctly. gcc, by default, looks in /usr/local/include
for the header files but NOT in /usr/local/lib for the libraries. The workaround
to avoid strange misconfigurations and link errors is to use the options
-L/usr/local/lib -Wl,-rpath,/usr/local/lib .)

$ ./configure --prefix=/usr/local --libdir=/usr/local/lib
--with-libiconv-prefix=/usr/local --with-libintl-prefix=/usr/local
--with-openssl=yes

Yes, this should work out of the box.

$ ./configure --help | grep -E 'thread|pth'
--enable-threads={posix|solaris|pth|windows}
specify multithreading API
--disable-threads build without multithread safety
--with-libpth-prefix[=DIR] search for libpth in DIR/include and DIR/lib
--without-libpth-prefix don't search for libpth in includedir and libdir
I left the threads in "auto" mode because I was not sure what was
preferred. I thought pth was dead and pthreads was dominant

pth was a makeshift for systems which did not have proper threads at
the OS level, more than 10 years ago. Nowadays, maybe Minix is the only system
where anyone would want to use pth.

but pth might still be preferred in some applications like coreutils.

No, coreutils definitely prefers POSIX threads if they are provided by the
OS.

I guess the next question is, should I specifically set
--enable-threads=pth for the ARM dev-board?

You did not say anything about the OS you're using. Which kernel? Which libc?

Also, you specified -Wl,--enable-new-dtags. Maybe you have a nonstandard pthreads
library in $LD_LIBRARY_PATH?

In any case, you can investigate yourself by running the test program
'test-rwlock1' using ltrace or strace.

Bruno