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): https://github.com/gentoo/gentoo/blob/master/eclass/meson.eclass#L251
(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?
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.
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.
(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.
$(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" > ^^^^^^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^
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).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3478cabb5f94e9d90ae1ed9e3f7909a1146aa471 commit 3478cabb5f94e9d90ae1ed9e3f7909a1146aa471 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-06 19:35:41 +0000 Commit: Sam James <sam@gentoo.org> 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 correctly. This avoids an issue where setup.py can't handle deducing libdir (or even being passed it) for cross-compilation. Fortunately, cpython is migrating away from setup.py 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. Bug: https://bugs.gentoo.org/633712 Bug: https://bugs.gentoo.org/794181 Bug: https://bugs.gentoo.org/864911 Signed-off-by: Sam James <sam@gentoo.org> 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(-)
