Re: [PATCH 1/5] selftests: Add futex functional tests

From: Darren Hart
Date: Mon May 11 2015 - 19:07:38 EST

On 5/11/15, 3:21 PM, "Shuah Khan" <shuahkh@xxxxxxxxxxxxxxx> wrote:

>>>>No need for a new pull request. Have you seen these errors before:
>>>>make[2]: Entering directory
>>>>for DIR in functional; do make -C $DIR all ; done
>>>>make[3]: Entering directory
>>>>gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>>>>futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>>>>/tmp/cc2UgUVs.o: In function `create_rt_thread':
>>>>undefined reference to `pthread_create'
>>>>/tmp/cc2UgUVs.o: In function `unit_test':
>>>>undefined reference to `pthread_join'
>>>>undefined reference to `pthread_join'
>>>>undefined reference to `pthread_join'
>>>>collect2: error: ld returned 1 exit status
>>>><builtin>: recipe for target 'futex_requeue_pi' failed
>>>>make[3]: *** [futex_requeue_pi] Error 1
>>>>make[3]: Leaving directory
>>>>Makefile:7: recipe for target 'all' failed
>>>>I am running make kselftest target when I saw the above build failures.
>>>>kselftest run doesn't fail which is good, however futex tests won't
>>>>run with this failure.
>>>I have not seen these errors whilst developing with futextest for the
>>>kernel. That looks like you may be missing the pthread development
>>>from your build machine.
>>>Those are provided by libc6-dev on my Debian systems.
>>I do have lib6-dev installed. timers uses pthread compiles fine.
>>So does mqueue. I am not sure what is going on with futex tests
>>though. I am guessing it has to do with library link order.
>>The following fixed it for me:
>>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>>+LDFLAGS := $(LDFLAGS) -pthread -lrt
>>Could you please make this change and resend the patch series.
>>I prefer patch series over pull request.
>>-- Shuah
>Sorry full diff:
>diff --git a/tools/testing/selftests/futex/functional/Makefile
>index e64d43b..b8a2e9b 100644
>--- a/tools/testing/selftests/futex/functional/Makefile
>+++ b/tools/testing/selftests/futex/functional/Makefile
>@@ -1,6 +1,6 @@
>INCLUDES := -I../include -I../../
>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>+LDFLAGS := $(LDFLAGS) -pthread -lrt

I'm happy to do that, but I would like to make sure I'm doing the right

I'm building with:
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2

What's there now works for me:
LDFLAGS := $(LDFLAGS) -lpthread -lrt

What you propose also works for me:
LDFLAGS := $(LDFLAGS) -pthread -lrt

I notice that most other test cases list -lrt first, including timers:
LDFLAGS += -lrt -lpthread

Which works for me for timers - does that work for you? I assume so. It
also works for futexes for me. I've found references out there suggesting
-lrt should always come before -lpthread.

I suspect you are correct as -pthread provides flags for both the
preprocessor and the linker, however, I'm still concerned about the

John - did you deliberately choose to use "-lrt -lpthread" ?

If ordering matters and -pthread is preferred over -lpthread, then perhaps
the "right way" is:

LDFLAGS += -lrt -pthread

Since -pthread also impacts the pre-processor, it seems that if used, it
should be present in both LDFLAGS as well as CFLAGS. However, I've also
read that -pthread is a non-standard compiler option and is best avoided.

If so, and if the reversed order works for you, "-lrt -lpthread", perhaps
that would be the "right fix".

I'd like to answer this once and for all for all tests we add to selftest.

Darren Hart
Intel Open Source Technology Center

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at