fix linking rt for glibc versions before 2.17

[guzhou2022]

Environment used: mips64 octeon toolchain have gcc 4.7 and glibc 2.16 ./configure CC=mips64-octeon-linux-gnu-gcc --host=mips64-octeon-linux-gnu --prefix=xxx build mips64 ltp get error

Some compilation errors are as follows, Other similar link errors will not be listed: CC lib/newlib_tests/tst_expiration_timer In file included from ../../include/tst_fuzzy_sync.h:69:0, from tst_fuzzy_sync01.c:68: ../../include/tst_timer.h: In function 'tst_ts_from_timespec': ../../include/tst_timer.h:614:3: warning: missing initializer [-Wmissing-field-initializers] ../../include/tst_timer.h:614:3: warning: (near initialization for 't.ts.libc_ts.tv_nsec') [-Wmissing-field-initializers] /tmp/ccSiwCw1.o: In function tst_fzsync_time': /home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: undefined reference toclock_gettime' /home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: undefined reference to clock_gettime' /home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: undefined reference toclock_gettime' /home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: undefined reference to clock_gettime' /home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: undefined reference toclock_gettime' /tmp/ccSiwCw1.o:/home/zc/zc/LTP/ltp-full-20220930/lib/newlib_tests/../../include/tst_fuzzy_sync.h:320: more undefined references to `clock_gettime' follow collect2: error: ld returned 1 exit status ../../include/mk/rules.mk:45: recipe for target 'tst_fuzzy_sync01' failed make[2]: [tst_fuzzy_sync01] Error 1 ../include/mk/generic_trunk_target.inc:108: recipe for target 'all' failed make[1]: [all] Error 2 make[1]: Leaving directory '/home/zc/zc/LTP/ltp-full-20220930/lib' Makefile:106: recipe for target 'lib-all' failed make: *** [lib-all] Error 2

View the Manual page clock_gettime(3), we should link with -lrt (only for glibc versions before 2.17). For glibc after 2.17, explicit linking with -lrt has no effect. To solve the above link problem, the patch is as follows: diff --git a/ltp-full-20220930/lib/newlib_tests/Makefile b/ltp-full-20220930/lib/newlib_tests/Makefile index 1fbf764..a915a7f 100644 --- a/ltp-full-20220930/lib/newlib_tests/Makefile +++ b/ltp-full-20220930/lib/newlib_tests/Makefile @@ -7,7 +7,7 @@ CFLAGS += -W -Wall LDLIBS += -lltp

test08 test09 test15 tst_fuzzy_sync01 tst_fuzzy_sync02 tst_fuzzy_sync03: CFLAGS += -pthread -tst_expiration_timer tst_fuzzy_sync03: LDLIBS += -lrt +tst_expiration_timer tst_fuzzy_sync01 tst_fuzzy_sync02 tst_fuzzy_sync03: LDLIBS += -lrt

ifeq ($(ANDROID),1) FILTER_OUT_MAKE_TARGETS += test08 diff --git a/ltp-full-20220930/testcases/kernel/fs/read_all/Makefile b/ltp-full-20220930/testcases/kernel/fs/read_all/Makefile index 0e6dec2..fb73e8f 100644 --- a/ltp-full-20220930/testcases/kernel/fs/read_all/Makefile +++ b/ltp-full-20220930/testcases/kernel/fs/read_all/Makefile @@ -6,5 +6,6 @@ top_srcdir ?= ../../../.. include $(top_srcdir)/include/mk/testcases.mk

CFLAGS += -D_GNU_SOURCE -pthread +read_all: LDLIBS+=-lrt

include $(top_srcdir)/include/mk/generic_leaf_target.mk diff --git a/ltp-full-20220930/testcases/kernel/syscalls/futex/Makefile b/ltp-full-20220930/testcases/kernel/syscalls/futex/Makefile index 7228496..1d05cf1 100644 --- a/ltp-full-20220930/testcases/kernel/syscalls/futex/Makefile +++ b/ltp-full-20220930/testcases/kernel/syscalls/futex/Makefile @@ -9,6 +9,9 @@ futex_wait02: LDLIBS+=-lrt futex_wake03: LDLIBS+=-lrt futex_wait05: LDLIBS+=-lrt futex_wait_bitset01: LDLIBS+=-lrt +futex_waitv01: LDLIBS+=-lrt +futex_waitv02: LDLIBS+=-lrt +futex_waitv03: LDLIBS+=-lrt

futex_wait03: CFLAGS+=-pthread futex_wake02: CFLAGS+=-pthread

[metan-ucw]

The changes looks good, can you send a proper patch to our mailing list or at least create a proper pull request?

[guzhou2022]

OK, I will submit a code merge request as soon as possible.

[Martchus]

The related PR https://github.com/linux-test-project/ltp/pull/1003 has been merged so I think this issue can be closed as completed.