https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-vcs/rsvndump fails to compile. Discovered on: amd64 NOTE: This machine uses a clang/LLVM toolchain. If you think that this issue is strictly related to clang/LLVM please mention it in the summary and block bug 408963.
Created attachment 647682 [details] build.log build log and emerge --info
Created attachment 647684 [details] other.tar.bz2 other logs
Hi Ago, similar to xmlstarlet bug #729600 I cannot reproduce it locally and it seems like a bug outside of rsnvdump but with the way the system and or the lld linker is set up. I can run this without errors locally: CC=x86_64-pc-linux-gnu-clang-10 \ CFLAGS="-O2 -pipe -march=native -frecord-gcc-switches -fno-diagnostics-color" \ LDFLAGS="-Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--defsym=__gentoo_check_ldflags__=0" \ ebuild rsvndump-0.6-r1.ebuild manifest clean install The crux is this piece of log from config.log that you provided: [..] configure:7795: x86_64-pc-linux-gnu-clang -o conftest -O2 -O2 -pipe -march=native -frecord-gcc-switches -fno-diagnostics-color -DNDEBUG -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--defsym=__gentoo_check_ldflags__=0 conftest.c -lsvn_fs-1 -L/usr/lib >&5 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../lib64/crt1.o is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../lib64/crti.o is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/crtbegin.o is incompatible with elf_x86_64 ld.lld: error: /var/tmp/portage/dev-vcs/rsvndump-0.6-r1/temp/conftest-e8727e.o is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../lib64/libsvn_fs-1.so is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/libgcc_s.so.1 is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/libgcc_s.so.1 is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/crtend.o is incompatible with elf_x86_64 ld.lld: error: /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../lib64/crtn.o is incompatible with elf_x86_64 clang-10: error: linker command failed with exit code 1 (use -v to see invocation) [..] I'm not sure how to address error "is incompatible with elf_x86_64" without being able to reproduce it locally. Best, Sebastian
Hello Sebastian, it looks like clang does not deal with -L/usr/lib in the link line.. The error comes from the fact that in /usr/lib we have 32 bit libraries
Hi Ago, a 32-64-bit-mixup would explain things. Why is /usr/lib containing 32bit libs on an amd64 box? For me, /usr/lib is a symlink to lib64 and it was not created manually. Where do you consider the part that needs fixing? What do you suggest we do to move forward?
(In reply to Sebastian Pipping from comment #5) > Hi Ago, > > a 32-64-bit-mixup would explain things. Why is /usr/lib containing 32bit > libs on an amd64 box? For me, /usr/lib is a symlink to lib64 and it was not > created manually. Where do you consider the part that needs fixing? What > do you suggest we do to move forward? I guess we should have: - /usr/lib with 32 bit libs - /usr/lib64 with 64 bit libs Otherwise if you have /usr/lib that points to /usr/lib64 where is the place for 32bit libs on your system? That's probably related to systems that did not pass to 17.1 profile. See https://bugs.gentoo.org/730232 as example for a possible fix
(In reply to Agostino Sarubbo from comment #6) > I guess we should have: > - /usr/lib with 32 bit libs I was not aware but news item 2019-06-05-amd64-17-1-profiles-are-now-stable seems to confirm what you're saying. > That's probably related to systems that did not pass to 17.1 profile. Could be, I ran it on a box with profile default/linux/amd64/17.0/developer . > See https://bugs.gentoo.org/730232 as example for a possible fix So we're looking for a place in rsvndump code that hardcodes /usr/lib but shouldn't, true? Does any of this look like the cause to you?: # ( cd /var/tmp/portage/dev-vcs/rsvndump-0.6-r1/work/ && fgrep -R usr/lib ) rsvndump-0.6/autom4te.cache/traces.1: dnl standard /usr/lib. rsvndump-0.6/autom4te.cache/traces.1: dnl 1. if it's the standard /usr/lib, rsvndump-0.6/autom4te.cache/traces.1: dnl No need to hardcode the standard /usr/lib. rsvndump-0.6/autom4te.cache/traces.1: dnl No need to hardcode the standard /usr/lib. rsvndump-0.6/autom4te.cache/traces.1: dnl 1. if it's the standard /usr/lib, rsvndump-0.6/m4/lib-prefix.m4: dnl 1. if it's the standard /usr/lib, rsvndump-0.6/m4/lib-link.m4: dnl standard /usr/lib. rsvndump-0.6/m4/lib-link.m4: dnl 1. if it's the standard /usr/lib, rsvndump-0.6/m4/lib-link.m4: dnl No need to hardcode the standard /usr/lib. rsvndump-0.6/m4/lib-link.m4: dnl No need to hardcode the standard /usr/lib. rsvndump-0.6/config.rpath: aix_libpath="/usr/lib:/lib" rsvndump-0.6/config.rpath: hardcode_libdir_flag_spec='${wl}-R $libdir:/usr/lib:/lib' rsvndump-0.6/config.rpath: if test -f /usr/libexec/ld.so; then
*** This bug has been marked as a duplicate of bug 739028 ***
