Discussion:
FAIL: test-rwlock1 on 32-bit ARM
(too old to reply)
Eric Blake
2018-02-06 14:17:25 UTC
Permalink
Raw Message
Adding gnulib, since test-rwlock1 is maintained by gnulib.

On 02/05/2018 11:04 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm building coreutils 8.29 on a CubieTruck v5. The CubieTruck uses a
> Cortex-A7. It runs a Ubuntu port:
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Linaro
> Description: Linaro 14.04
> Release: 14.04
> Codename: trusty
>
> And:
>
> $ gcc --version
> gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2
>
> I'm seeing one failed self test:
>
> ...
> PASS: test-locale
> PASS: test-localeconv
> PASS: test-localename
> ../build-aux/test-driver: line 107: 10631 Aborted "$@" > $log_file 2>&1
> FAIL: test-rwlock1
> PASS: test-lock
> PASS: test-lseek.sh
> PASS: test-lstat
> ...
>
> A little further down I see:
>
> FAIL: test-rwlock1
> ==================
>
> Unexpected outcome 3
> FAIL test-rwlock1 (exit status: 134)
>
> Any ideas what I might be doing wrong?
>
> Thanks in advance.
>
>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Bruno Haible
2018-02-06 17:11:35 UTC
Permalink
Raw Message
Hi,

Jeffrey Walton wrote:
> > 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
2018-02-06 19:48:38 UTC
Permalink
Raw Message
Jeffrey Walton wrote:
> Here was the environment I used:
>
> 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 .)

> Here was the configure line taken from config.log:
>
> $ ./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.

> I see configure offers:
>
> $ ./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
Loading...