Summary: | dev-libs/libbsd-0.11.3 does not respect SYSROOT | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hoelbezier |
Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://savannah.gnu.org/support/?110537 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | `emerge --root=/opt/libbsd-test --sysroot=/opt/libbsd-test dev-libs/libbsd` build.log |
Description
hoelbezier
2021-09-09 09:46:53 UTC
Setting CFLAGS="${CFLAGS} --sysroot=/libbsd-test" fixes the issue. It would seem autoconf-generated configure scripts are broken in regard to the --with-sysroot option (on which ebuilds rely). I'm assuming this (https://savannah.gnu.org/support/?110537) is your bug upstream to autoconf? If so, remember to cross-link -- it's really useful. Thanks for the report(s)! It’s not, someone else did it. I planned to report upstream this morning. Keeping in mind that I should cross-link issues. :) autoconf's --with-sysroot only does so much. I think it's mainly used by libtool when relinking. Of course, not everything uses autotools either, and I'm not aware of even CMake or Meson having an equivalent. I think it was implied that a long time that Gentoo only supported cross-compiling into the /usr/${CHOST} environment set up by crossdev. I recall seeing many reports by users failing to set up environments elsewhere, getting little official help, and trying to fudge in nasty workarounds like -L/libbsd-test/usr/lib64. That didn't get them far. I think I discovered --sysroot for myself, but I found that inserting it into CFLAGS wasn't that reliable. By far the most reliable method is to set CC="${CHOST}-gcc --sysroot=/libbsd-test" and the same for CXX. This probably works so well because we support multilib by injecting -m32 into CC and CXX. I have long wondered whether Portage should do this for you, especially since EAPI 7, but I haven't quite convinced myself yet. In your case, you're not actually cross-compiling. My personal stance is that we shouldn't go out of our way to support the native SYSROOT!=/ case because it's not really feasible. If the build tries to execute something because it's not cross-compiling then it will almost certainly fail due to using libraries from / rather than SYSROOT or ROOT. The best chance of making this work is to force it to think you are cross-compiling, either by building an alternative toolchain like x86_64-cross-linux-gnu, or by forcing the build systems somehow. But what's the point when you may as well chroot instead? |