Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 730820 - dev-vcs/rsvndump fails to compile with 17.1 profile (with 32bit libs in /usr/lib on amd64)
Summary: dev-vcs/rsvndump fails to compile with 17.1 profile (with 32bit libs in /usr/...
Status: IN_PROGRESS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sebastian Pipping
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: LD-is-lld
  Show dependency tree
 
Reported: 2020-07-05 08:22 UTC by Agostino Sarubbo
Modified: 2020-07-06 08:19 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,11.97 KB, text/plain)
2020-07-05 08:22 UTC, Agostino Sarubbo
Details
other.tar.bz2 (other.tar.bz2,7.56 KB, application/x-bzip-compressed-tar)
2020-07-05 08:22 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2020-07-05 08:22:32 UTC
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.
Comment 1 Agostino Sarubbo gentoo-dev 2020-07-05 08:22:37 UTC
Created attachment 647682 [details]
build.log

build log and emerge --info
Comment 2 Agostino Sarubbo gentoo-dev 2020-07-05 08:22:41 UTC
Created attachment 647684 [details]
other.tar.bz2

other logs
Comment 3 Sebastian Pipping gentoo-dev 2020-07-05 10:37:40 UTC
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
Comment 4 Agostino Sarubbo gentoo-dev 2020-07-05 13:22:05 UTC
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
Comment 5 Sebastian Pipping gentoo-dev 2020-07-05 14:14:59 UTC
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?
Comment 6 Agostino Sarubbo gentoo-dev 2020-07-05 15:56:16 UTC
(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
Comment 7 Sebastian Pipping gentoo-dev 2020-07-05 17:50:23 UTC
(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