Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 945108 - multilib.eclass should respect SYSROOT when overriding PKG_CONFIG path vars
Summary: multilib.eclass should respect SYSROOT when overriding PKG_CONFIG path vars
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-27 10:18 UTC by Matt Whitlock
Modified: 2024-11-27 10:18 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Whitlock 2024-11-27 10:18:01 UTC
In multilib.eclass, multilib_toolchain_setup() overrides the environment variables PKG_CONFIG_LIBDIR, PKG_CONFIG_PATH, PKG_CONFIG_SYSTEM_INCLUDE_PATH, and PKG_CONFIG_SYSTEM_LIBRARY_PATH so that the .pc files for the correct ABI will be found and used, as follows:

export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
export PKG_CONFIG_SYSTEM_INCLUDE_PATH=${EPREFIX}/usr/include
export PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/$(get_libdir):${EPREFIX}/usr/$(get_libdir)

As a reminder, pkgconfig is normally called upon to find packages that have been installed into the *host* system — i.e., packages listed in DEPEND. The "Ebuild writing: Variables" page[1] describes the SYSROOT variable as "(EAPI=7) The absolute path to the root directory containing build dependencies satisfied by DEPEND" and ESYSROOT as "(EAPI=7) Shorthand for ${SYSROOT%/}${EPREFIX}/." (That latter definition seems to be wrong, as the value of ESYSROOT apparently does not always end in a slash.)

[1] https://devmanual.gentoo.org/ebuild-writing/variables/

In order to support the use case of setting SYSROOT to a path other than / while building packages for ABIs other than the default ABI, it is necessary to change the above lines in multilib.eclass to:

export PKG_CONFIG_LIBDIR=${ESYSROOT%/}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${ESYSROOT%/}/usr/share/pkgconfig
export PKG_CONFIG_SYSTEM_INCLUDE_PATH=${ESYSROOT%/}/usr/include
export PKG_CONFIG_SYSTEM_LIBRARY_PATH=${ESYSROOT%/}/$(get_libdir):${ESYSROOT%/}/usr/$(get_libdir)

(It is also necessary to set PKG_CONFIG_SYSROOT_DIR in make.conf, but that's left for the user to do.)

The user story motivating this request:

* My amd64 Gentoo installation in "/" uses a multilib profile but does not have any installed packages configured for non-default ABIs.

* I have set up a chroot to host Steam (which requires 32-bit libraries) using `emerge --config-root=/chroot/steam --sysroot=/chroot/steam games-util/steam-launcher::steam-overlay`.

* My /chroot/steam/etc/portage/make.conf contains:
  source /etc/portage/make.conf
  ROOT="/chroot/steam"
  SYSROOT="${ROOT}"
  CFLAGS="${CFLAGS} --sysroot=${SYSROOT}"
  CXXFLAGS="${CXXFLAGS} --sysroot=${SYSROOT}"
  LDFLAGS="${LDFLAGS} -Wl,-rpath-link,${SYSROOT}/usr/\\\$LIB"
  PKG_CONFIG_SYSROOT_DIR="${SYSROOT}"
  PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib64/pkgconfig"
  PKG_CONFIG_PATH="${SYSROOT}/usr/share/pkgconfig"
  LD_LIBRARY_PATH="${SYSROOT}/usr/lib64:${SYSROOT}/usr/lib"
  LD_RUN_PATH="${SYSROOT}/usr/\$LIB"
  ABI_X86="32"

* The above is almost sufficient to successfully build all dependencies of games-util/steam-launcher. However, without my proposed changes to multilib.eclass, packages fail while configuring for the 32-bit ABI because they are trying to find their dependencies beneath "/" rather than beneath "/chroot/steam".

* After I make the proposed changes to multilib.eclass, I am able to build all dependencies of games-util/steam-launcher successfully.

* For Gentoo users who do not set SYSROOT, this proposed change will have no bearing.

* This change could conceivably affect crossdev users, but I think typically crossdev sysroots do not support multilib anyway, so this change wouldn't affect them either.