During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org --- tools/testing/selftests/x86/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 5d49bfec1e9a..f8360454eafd 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -71,10 +71,10 @@ all_64: $(BINARIES_64) EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64)
$(BINARIES_32): $(OUTPUT)/%_32: %.c - $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm + $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $(LDFLAGS) $^ $(LDLIBS) -lrt -ldl -lm
$(BINARIES_64): $(OUTPUT)/%_64: %.c - $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl + $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $(LDFLAGS) $^ $(LDLIBS) -lrt -ldl
# x86_64 users should be encouraged to install 32-bit libraries ifeq ($(CAN_BUILD_I386)$(CAN_BUILD_X86_64),01)
During cross-compilation, it was discovered that LDFLAGS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org --- tools/testing/selftests/rseq/Makefile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile index d6469535630a..2d2d0c283de1 100644 --- a/tools/testing/selftests/rseq/Makefile +++ b/tools/testing/selftests/rseq/Makefile @@ -22,15 +22,15 @@ TEST_PROGS = run_param_test.sh include ../lib.mk
$(OUTPUT)/librseq.so: rseq.c rseq.h rseq-*.h - $(CC) $(CFLAGS) -shared -fPIC $< $(LDLIBS) -o $@ + $(CC) $(CFLAGS) $(LDFLAGS) -shared -fPIC $< $(LDLIBS) -o $@
$(OUTPUT)/%: %.c $(TEST_GEN_PROGS_EXTENDED) rseq.h rseq-*.h - $(CC) $(CFLAGS) $< $(LDLIBS) -lrseq -o $@ + $(CC) $(CFLAGS) $(LDFLAGS) $< $(LDLIBS) -lrseq -o $@
$(OUTPUT)/param_test_benchmark: param_test.c $(TEST_GEN_PROGS_EXTENDED) \ rseq.h rseq-*.h - $(CC) $(CFLAGS) -DBENCHMARK $< $(LDLIBS) -lrseq -o $@ + $(CC) $(CFLAGS) $(LDFLAGS) -DBENCHMARK $< $(LDLIBS) -lrseq -o $@
$(OUTPUT)/param_test_compare_twice: param_test.c $(TEST_GEN_PROGS_EXTENDED) \ rseq.h rseq-*.h - $(CC) $(CFLAGS) -DRSEQ_COMPARE_TWICE $< $(LDLIBS) -lrseq -o $@ + $(CC) $(CFLAGS) $(LDFLAGS) -DRSEQ_COMPARE_TWICE $< $(LDLIBS) -lrseq -o $@
During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org --- tools/testing/selftests/bpf/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index e2fd6f8d579c..f1740113d5dc 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -88,7 +88,7 @@ $(notdir $(TEST_GEN_PROGS) \ $(TEST_CUSTOM_PROGS)): %: $(OUTPUT)/% ;
$(OUTPUT)/urandom_read: urandom_read.c - $(CC) -o $@ $< -Wl,--build-id + $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) -Wl,--build-id
$(OUTPUT)/test_stub.o: test_stub.c $(CC) -c $(CFLAGS) -o $@ $<
On Fri, Jan 17, 2020 at 8:55 AM Daniel Díaz daniel.diaz@linaro.org wrote:
During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org
Acked-by: Andrii Nakryiko andriin@fb.com
tools/testing/selftests/bpf/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index e2fd6f8d579c..f1740113d5dc 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -88,7 +88,7 @@ $(notdir $(TEST_GEN_PROGS) \ $(TEST_CUSTOM_PROGS)): %: $(OUTPUT)/% ;
$(OUTPUT)/urandom_read: urandom_read.c
$(CC) -o $@ $< -Wl,--build-id
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) -Wl,--build-id$(OUTPUT)/test_stub.o: test_stub.c $(CC) -c $(CFLAGS) -o $@ $< -- 2.20.1
Andrii Nakryiko wrote:
On Fri, Jan 17, 2020 at 8:55 AM Daniel Díaz daniel.diaz@linaro.org wrote:
During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org
Acked-by: Andrii Nakryiko andriin@fb.com
Acked-by: John Fastabend john.fastabend@gmail.com
On 1/17/20 5:53 PM, Daniel Díaz wrote:
During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org
Applied, thanks!
Daniel Díaz daniel.diaz@linaro.org writes:
During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct.
OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS?
Signed-off-by: Daniel Díaz daniel.diaz@linaro.org
Acked-by: Thomas Gleixner tglx@linutronix.de
linux-kselftest-mirror@lists.linaro.org
-
Andrii Nakryiko -
Daniel Borkmann -
Daniel Díaz -
John Fastabend -
Thomas Gleixner