algaos/algaos-ebuild-tree/eclass/multilib.eclass, branch next

Revert "multilib.eclass: handle multilib on Hurd in multilib_env"

2026-03-30T13:24:25Z

This reverts commit a451db0ab5a75365e4198ded7d9c537f3cdb8185. This doesn't seem needed after 0e69f61dfc063153d124132ef7fd9b5959d99619. Signed-off-by: Sam James

multilib.eclass: handle multilib on Hurd in multilib_env

2026-03-30T11:24:15Z

We need this otherwise glibc will try to install to the wrong directory on Hurd for the cross package (as we don't have a profile at that point). Signed-off-by: Sam James

multilib.eclass: convert musl check to case statement

2026-03-30T11:13:29Z

In preparation for another check, for Hurd. Signed-off-by: Sam James

multilib.eclass: derive BUILD_* before appending ABI flags

2026-01-03T09:01:47Z

Per [1], we cannot have ${MULTILIB_USEDEP} in BDEPEND because it would break cross-compiles, as ${MULTILIB_USEDEP} specifies ABIs of CHOST, not of CBUILD. However, this leads to a problem, as multilib.eclass does not preserve the default build-machine toolchain before it appends the ABI flags to the host-machine toolchain. Thus, when $(tc-getBUILD_CC) later pulls a default value for BUILD_CC from CC, the ABI flags have already been appended to CC, and BUILD_CC inherits those flags, thus causing any build-time helper executables to be built for a non-default ABI, whose build-time dependencies may not be installed in ${BROOT} since ${MULTILIB_USEDEP} makes no sense in BDEPEND. Note, the behavior is inconsistent if the user has set BUILD_CC and friends via their package.env, as then the ABI flags are *not* applied to the build-machine toolchain via defaulting from the host-machine toolchain. This commit fixes up multilib.eclass so that it derives the build- machine toolchain variables _before_ it appends the ABI flags to the host-machine toolchain variables and so that it overrides CBUILD to the default ABI in the non-cross-compiling case. The result is that build- time helper executables are always built for the build machine's _default_ ABI, even in the non-cross-compiling case. [1] https://bugs.gentoo.org/960506#c9 Bug: https://bugs.gentoo.org/960506 Signed-off-by: Matt Whitlock Signed-off-by: James Le Cuirot

multilib.eclass: respect SYSROOT when overriding PKG_CONFIG_* vars

2025-08-20T22:26:47Z

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 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 "The absolute path to the root directory containing build dependencies satisfied by DEPEND" and ESYSROOT as "The same as either EROOT, BROOT or SYSROOT depending on the value of SYSROOT. Commonly used to reference the location of headers and libraries at build time." 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, change multilib.eclass so that it prefixes the PKG_CONFIG_* vars with ${ESYSROOT} rather than ${EPREFIX}. For Gentoo users who do not set SYSROOT, this 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. [1] https://devmanual.gentoo.org/ebuild-writing/variables/ Closes: https://bugs.gentoo.org/945108 Signed-off-by: Matt Whitlock Part-of: https://github.com/gentoo/gentoo/pull/43088 Closes: https://github.com/gentoo/gentoo/pull/43088 Signed-off-by: James Le Cuirot

multilib.eclass: drop support for EAPI 6

2024-10-08T15:31:18Z

Signed-off-by: David Seifert

multilib.eclass: add global-scope ewarn for deprecated < EAPI 7

2024-09-08T18:21:12Z

Signed-off-by: Sam James

multilib.eclass: drop dead prefix targets

2023-05-29T18:19:05Z

Signed-off-by: Sam James

multilib.eclass: Drop CONF_LIBDIR

2023-05-10T17:57:18Z

The CONF_LIBDIR variable was used exclusively in the 2004.3 profile (i.e. it was no longer defined in 2005.0), before the ABI and LIBDIR_${ABI} variables existed. Simply use "lib" as default, which is consistent with get_libdir(). Bug: https://bugs.gentoo.org/267159 Signed-off-by: Ulrich Müller

multilib.eclass: fix spelling

2023-03-26T11:36:03Z

Thanks to codespell. Signed-off-by: Sam James Signed-off-by: Ulrich Müller