Build fails in tests/ subdirectory (even when tests are not executed) because libunwind-x86_64.so is missing a dependency on liblzma. Reproducible: Always Steps to Reproduce: binutils-config --linker ld.gold USE=lzma emerge -1 libunwind Actual Results: /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -O2 -pipe -fexceptions -Wall -Wsign-compare -Wl,-O1 -Wl,--as-needed -o Gperf-simple Gperf-simple.o ../src/libunwind-x86_64.la ../src/libunwind.la libtool: link: x86_64-pc-linux-gnu-gcc -O2 -pipe -fexceptions -Wall -Wsign-compare -Wl,-O1 -o .libs/Gperf-simple Gperf-simple.o -Wl,--as-needed ../src/.libs/libunwind-x86_64.so ../src/.libs/libunwind.so ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_stream_footer_decode' ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_index_buffer_decode' ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_index_size' ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_index_end' ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_index_uncompressed_size' ../src/.libs/libunwind-x86_64.so: error: undefined reference to 'lzma_stream_buffer_decode' collect2: error: ld returned 1 exit status Makefile:683: recipe for target 'Gperf-simple' failed make[1]: *** [Gperf-simple] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-libs/libunwind-1.1/work/libunwind-1.1/tests' Makefile:476: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1
Created attachment 370430 [details] build.log
Created attachment 370432 [details] emerge --info libunwind
sort of 2 issues here: tests are restricted in the ebuild due to other issues, so it shouldn't even build the tests/ subdirectory where the failure is but of course, it should still build, so proper linking is required
underlinking problem?
(In reply to Alex Xu (Hello71) from comment #4) > underlinking problem? Yes, but it's not 100% clear where it comes from. Running autoreconf in the source directory before building seems to fix it, but I'm not sure why. That way, libtool eventually calls the linker as follows: gcc -O2 -pipe -fexceptions -Wall -Wsign-compare -Wl,-O1 -Wl,--as-needed -o .libs/test-coredump-unwind test-coredump-unwind.o ../src/.libs/libunwind-coredump.so ../src/.libs/libunwind-x86_64.so /home/maks/test/libunwind-1.1/src/.libs/libunwind.so -lgcc -llzma -lc ... without running autoreconf, -lgcc and -llzma are missing from that command, but I'm not sure yet what happens between autoconf and linking that causes this. By the way, the ebuild currently contains this line: sed -i -e '/LIBLZMA/s:-lzma:-llzma:' configure{,.ac} || die #444050 .. however, this is a red herring. Although this does fix a typo, LIBLZMA is actually not used anywhere; the configure code that sets LIBLZMA also sets HAVE_LZMA and that is what is used in src/Makefile.am. So the analysis at Bug #444050 (fix the typo, then rerun autoreconf) is wrong: fixing the typo doesn't matter, it's running autoreconf that fixes the problem. Editing the configure script directly (to avoid having to rerun autoconf) does not fix the problem.
*** This bug has been marked as a duplicate of bug 444050 ***
Created attachment 370530 [details, diff] Patch for libunwind-1.1.ebuild Turns out autoreconf fixes the problem because Gentoo's aclocal sets the libtool parameter link_all_deplibs to `unknown` while the bundled aclocal.m4 has it set to `no`, which arguably is an upstream bug (either libunwind-x86_64.la should include -llzma as a dependency, or link_all_deplibs should be `yes`, so that the dependency gets picked up recursively from libunwind.la.) Attached patch fixes the problem by removing the link_all_deplibs...=no lines, which resolves my issue and I think also fixes bug #444050 (which I don't think was actually solved before).
(In reply to Maks Verver from comment #7) i don't think that is the correct fix. see the patch i committed.
(In reply to SpanKY from comment #8) > (In reply to Maks Verver from comment #7) > > i don't think that is the correct fix. see the patch i committed. Even better. Thanks. (I hope upstream fixes this in Makefile.am at some point, otherwise you have to keep editing the Makefile templates, which is still pretty hackish.)
