Hi Martin, On Thu, 2020-06-11 at 20:51 +0200, Martin Liška wrote: > On 6/11/20 8:31 PM, Martin Liška wrote: > > On 6/11/20 7:48 PM, Mark Wielaard wrote: > > > ELFUTILS 0.180 -http://elfutils.org/ > > > > Thank you for the release. I'm seeing a linking error during test > > build: > > > > [ 84s] gcc -D_GNU_SOURCE -DHAVE_CONFIG_H > > -DLOCALEDIR='"/usr/share/locale"' -I. -I.. \ > > [ 84s] -I. -I. -I../lib -I.. -I../libasm -I../libdw > > -I../libdwfl -I../libdwelf -I../libebl -I../libelf -I../lib -I.. \ > > [ 84s] -g -O0 ../libelf/libelf.so -o test-nlist test-nlist.c > > [ 84s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64- > > suse-linux/bin/ld: /tmp/ccyqAIyN.o: in function `main': > > [ 84s] /home/abuild/rpmbuild/BUILD/elfutils-0.180/tests/test- > > nlist.c:49: undefined reference to `nlist' > > [ 84s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64- > > suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/elfutils- > > 0.180/tests/test-nlist.c:50: undefined reference to `nlist' > > [ 84s] collect2: error: ld returned 1 exit status > > [ 84s] make[2]: *** [Makefile:4516: test-nlist] Error 1 > > [ 84s] make[2]: *** Waiting for unfinished jobs.... > > > > Small analysis: > > $ gcc test-nlist.c -I../libelf -c > $ gcc test-nlist.o ../libelf/libelf.so > $ gcc ../libelf/libelf.so test-nlist.o > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > linux/bin/ld: test-nlist.o: in function `main': > test-nlist.c:(.text+0x91): undefined reference to `nlist' > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > linux/bin/ld: test-nlist.c:(.text+0xab): undefined reference to > `nlist' > collect2: error: ld returned 1 exit status > > apparently gold is fine: > > $ gcc ../libelf/libelf.so test-nlist.o -fuse-ld=gold > [ok] > > $ objdump -t test-nlist.o | grep nlist > test-nlist.o: file format elf64-x86-64 > 0000000000000000 l df *ABS* 0000000000000000 test-nlist.c > 0000000000000000 *UND* 0000000000000000 nlist > > $ objdump -t ../libelf/libelf.so | grep nlist > 0000000000000000 l df *ABS* 0000000000000000 n > list.c > 00000000000113a0 l F .text 00000000000000f1 n > list_fshash_lookup > 00000000000114a0 g F .text 0000000000000388 n > list > > May it be related to some order mentioned in > 51cfbaabefd6d5ebdd7513b876daf78d07470f8c?
Interesting. I saw the same when I tried to generate the coverage report: https://sourceware.org/elfutils/coverage/ I first assume the ordering was the issue, so I added the LD_ADD later, then I saw that it was missing the coverage CFLAGS and so added those. Assuming that was the issue. What happens if you apply: commit 3eaa4421b2422452b40547aab3e8da0749990ef9 Which has: - $(test_nlist_CFLAGS) $(test_nlist_LDADD) -o $@ $< + $(test_nlist_CFLAGS) $(GCOV_FLAGS) -o $@ $< $(test_nlist_LDADD) Note that beside the GCOV_FLAGS, it also puts LDADD at the end. Cheers, Mark
