Summary: | sys-libs/libunwind-1.1[lzma] - linking fails using ld.gold (../src/.libs/libunwind-x86_64.so: undefined reference to 'lzma_stream_footer_decode') | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maks Verver <maksverver> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alex_y_xu, esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 269315, 461394 | ||
Attachments: |
build.log
emerge --info libunwind Patch for libunwind-1.1.ebuild |
Description
Maks Verver
2014-02-14 21:06:42 UTC
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.) |