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
Yes, this should work out of the box.
> 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
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
> 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.