[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FAIL: test-rwlock1 on 32-bit ARM
From: |
Jeffrey Walton |
Subject: |
Re: FAIL: test-rwlock1 on 32-bit ARM |
Date: |
Tue, 6 Feb 2018 14:29:22 -0500 |
On Tue, Feb 6, 2018 at 12:11 PM, Bruno Haible <address@hidden> wrote:
> 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.
Thanks Bruno.
Sorry for not supplying some of the information. It is easy to
overwhelm the list with the log dumps. You know its bad when Pastebin
rejects it because it is too big...
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
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
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, but pth
might still be preferred in some applications like coreutils. So if
coreutils wants pth, then coreutils should be able to use pth.
I guess the next question is, should I specifically set
--enable-threads=pth for the ARM dev-board?
(The same configuration does not produce an error on x86_64, i686 or Aarch64).
Jeff