Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 794181 - [Future EAPI] ROOT-awareness for get_libdir
Summary: [Future EAPI] ROOT-awareness for get_libdir
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi 762454 793050
  Show dependency tree
Reported: 2021-06-04 16:40 UTC by David Michael
Modified: 2022-12-06 20:22 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description David Michael 2021-06-04 16:40:38 UTC
The get_libdir function currently outputs the value of LIBDIR_$ABI, which corresponds to the target root file system.  When cross-compiling, sometimes libdir must also be determined for native settings in BROOT.

I would suggest a future EAPI defines "get_libdir -b" to output the value of LIBDIR from $BROOT/etc/portage.  (Perhaps -d and -r could be accepted as well for consistency with has_version arguments.)

For example, currently any meson package that calls native pkg-config will fail to cross-compile when the target libdir does not match BROOT (e.g. building for arm on amd64):
Comment 1 Ulrich Müller gentoo-dev 2021-06-09 07:39:15 UTC
(In reply to David Michael from comment #0)
> I would suggest a future EAPI defines "get_libdir -b" to output the value of
> LIBDIR from $BROOT/etc/portage.  (Perhaps -d and -r could be accepted as
> well for consistency with has_version arguments.)

I fear we cannot read /etc/portage because it is Portage specific. Is there any other way to obtain that information, independently of the package manager?
Comment 2 David Michael 2021-06-09 14:07:31 UTC
Skimming the PMS, I don't see anything that notes BROOT has a different profile.  I don't know how to get this info with such limitations.
Comment 3 Ulrich Müller gentoo-dev 2021-06-09 15:11:44 UTC
I'm not sure if I entirely understand the problem. libdir should be used only for installing libs, which isn't relevant for build tools:

 -- Variable: libdir
     The directory for installing object code libraries.

As for pkg-config, shouldn't it use the correct lib location by default? For example, if the CBUILD system is amd64, then the native pkg-config binary should have /usr/lib64/pkgconfig in its default search path.
Comment 4 Mike Gilbert gentoo-dev 2021-06-09 16:06:02 UTC
(In reply to Ulrich Müller from comment #3)

Yeah, it's possible we might be able to avoid this by tweaking meson.eclass to not output pkg_config_libdir in the native machine file when cross-compiling. Hopefully that will cause it to use the default path built in to pkg-config.
Comment 5 Arfrever Frehtes Taifersar Arahesis 2021-06-09 16:40:13 UTC
$(get_libdir -b) may be needed for building tools which are executed at build time (and not installed).

E.g. for building of tool which uses headers from dev-libs/glib:2, options passed to compiler would need to contain:
> -I"${BROOT}/usr/include/glib-2.0" -I"${BROOT}/usr/$(get_libdir -b)/glib-2.0/include"
>    ^^^^^^^^                          ^^^^^^^^     ^^^^^^^^^^^^^^^^
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-12-06 19:13:01 UTC
As Arfrever notes, this is rather problematic if you need to do any building of a binary for CBUILD, like how dev-lang/python must build a CBUILD Python first for cross-compilation before building a cross-compiled CHOST Python.

econf_build from toolchain-funcs.eclass almost does the job, but it passes an incorrect --libdir (using CHOST's).
Comment 7 Larry the Git Cow gentoo-dev 2022-12-06 19:39:17 UTC
The bug has been referenced in the following commit(s):

commit 3478cabb5f94e9d90ae1ed9e3f7909a1146aa471
Author:     Sam James <>
AuthorDate: 2022-12-06 19:35:41 +0000
Commit:     Sam James <>
CommitDate: 2022-12-06 19:38:51 +0000

    dev-lang/python: disable _ctypes, _crypt for cross (CBUILD) Python
    * Use a hack to deduce libdir to nudge the build system in the right
      direction because get_libdir can't handle BROOT/CBUILD right now.
    * Disable _ctypes (libffi) and _crypt (lib(x)crypt) modules for cross (CBUILD)
      Python as they're not needed and Python struggles to find the libraries
      This avoids an issue where can't handle deducing libdir
      (or even being passed it) for cross-compilation. Fortunately, cpython
      is migrating away from to autotools.
    Note that this isn't the same as what bug 633712 would've been at the time
    it was reported, but it certainly showed up the same way on more modern
    Pythons since we introduced the CBUILD part a few months ago.
    Signed-off-by: Sam James <>

 dev-lang/python/python-3.10.8_p3.ebuild     | 13 +++++++++++--
 dev-lang/python/python-3.11.0_p2.ebuild     | 13 +++++++++++--
 dev-lang/python/python-3.12.0_alpha2.ebuild | 13 +++++++++++--
 dev-lang/python/python-3.8.15_p3.ebuild     | 13 +++++++++++--
 dev-lang/python/python-3.9.15_p3.ebuild     | 13 +++++++++++--
 5 files changed, 55 insertions(+), 10 deletions(-)