[Top][All Lists]

[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

I see configure offers:

    $ ./configure --help | grep -E 'thread|pth'
                              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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]