Summary: | sys-libs/libunwind-1.2 with CCACHE: libunwind-dwarf-local.a(Lstep.o): multiple definition of '_ULx86_64_step' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matt Whitlock <gentoo> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Matt Whitlock
2016-06-17 15:45:48 UTC
can you try w/out -ggdb ? (In reply to SpanKY from comment #1) > can you try w/out -ggdb ? Same error without -ggdb. I also tried with "-O1" instead of "-O3 -ggdb", and that still failed in the exact same way. Isn't the link command line just wrong? It includes both Lstep.o and libunwind-dwarf-local.a, but the latter contains the former, so of course there will be multiple definitions. I ran into this problem again in sys-libs/libunwind-1.2, so I set out to diagnose it. As it turns out, the link command is not wrong: there are in fact two different Lstep.o objects, one compiled from src/x86_64/Lstep.c and one compiled from src/dwarf/Lstep.c. The problem was that these two source files are byte-for-byte identical, and ccache's "direct mode" apparently doesn't record the full paths of included local files, so despite that the two Gstep.c files included by the two Lstep.c files are different, ccache wasn't noticing this. The solution was to set CCACHE_NODIRECT=1 (via /etc/portage/package.env) for sys-libs/libunwind. Now it builds successfully. I'd suggest adding this environment variable to the ebuild to save other ccache users this headache. (In reply to Matt Whitlock from comment #3) > I ran into this problem again in sys-libs/libunwind-1.2, so I set out to > diagnose it. > > As it turns out, the link command is not wrong: there are in fact two > different Lstep.o objects, one compiled from src/x86_64/Lstep.c and one > compiled from src/dwarf/Lstep.c. The problem was that these two source files > are byte-for-byte identical, and ccache's "direct mode" apparently doesn't > record the full paths of included local files, so despite that the two > Gstep.c files included by the two Lstep.c files are different, ccache wasn't > noticing this. The solution was to set CCACHE_NODIRECT=1 (via > /etc/portage/package.env) for sys-libs/libunwind. Now it builds > successfully. I'd suggest adding this environment variable to the ebuild to > save other ccache users this headache. That looks both harmless and useful. Added to 1.2 and 1.2.1. (In reply to Andreas K. Hüttel from comment #4) > That looks both harmless and useful. Added to 1.2 and 1.2.1. Thanks for your effort, but your modification to the ebuild is ineffective. CCACHE_NODIRECT=1 needs to be exported to the environment in the src_compile phase. multilib_src_compile() { # Bug 586208 CCACHE_NODIRECT=1 default } The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=acd563315f0606f21b3453d9449c2be756edcf28 commit acd563315f0606f21b3453d9449c2be756edcf28 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-10-04 09:30:50 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-10-04 09:31:14 +0000 sys-libs/libunwind: Fix bug 586208 properly this time Closes: https://bugs.gentoo.org/586208 Package-Manager: Portage-2.3.11, Repoman-2.3.3 sys-libs/libunwind/libunwind-1.2.1.ebuild | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) |