Created attachment 869499 [details] irc-log from #gentoo On arm64 machine the default settings and tarballs (stage3 stuff built by gentoo) wants the pkgconfig in /usr/lib64` however crossdev automatically changes it to /usr/lib/pkgconfig which results in failures due to missing deps when moving to the actual system. The cross amd64 system was generated by: crossdev --stable -t aarch64-unknown-linux-gnu I brought this issue to `#gentoo`, the relevant conversation is provided in the attachment, as well as relevant logs.
Created attachment 869501 [details] emerge-info from arm64 host
Created attachment 869502 [details] cross amd64 to arm64 emerge --info
I'm wondering if this is somehow usrmerge related and the crossdev-pkg-config wrapper is being hidden as a result (although we should really generate the line in make.conf to be correct anyway).
Created attachment 869503 [details] example error when building mesa
crossdev does set PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" in make.conf, as you say, which is just wrong and should be removed, but cross-pkg-config unsets PKG_CONFIG_PATH, so it probably doesn't make any difference... assuming that cross-pkg-config is actually being used here. Sam is probably right.
From crossdev: ``` cross_wrap_bin() { [[ $1 == "-q" ]] || echo "${CHOST}: Setting up symlinks" pushd "${0%/*}" >/dev/null local wrapper for wrapper in ebuild emerge fix-root pkg-config ; do ln -sf cross-${wrapper} ${CHOST}-${wrapper} done # some people like their tab completion ln -sf cross-emerge emerge-${CHOST} popd >/dev/null } cross_wrap() { SYSROOT=@GENTOO_PORTAGE_EPREFIX@/usr/${CHOST} cross_wrap_bin "$@" || return $? if [[ -d ${SYSROOT} ]] && [[ ! -d ${SYSROOT}/etc ]] ; then cross_wrap_etc "$@" fi return $? } ``` and from wrappers/Makefile: ``` FNAMES = cross-ebuild cross-emerge cross-fix-root cross-pkg-config emerge-wrapper [...] install: [...] $(INSTALL_EXEC) $(FNAMES) $(DESTDIR)$(PREFIX)/bin/ ```
Wait, wait... I think our wires might be crossed here. It fails when you're doing a *native* build, having cross-built the dependency earlier? During the native build, it won't use cross-pkg-emerge, so it won't unset PKG_CONFIG_PATH, and the wrong value will be used, assuming you've copied that wrong value into your native environment.
(In reply to James Le Cuirot from comment #7) > Wait, wait... I think our wires might be crossed here. It fails when you're > doing a *native* build, having cross-built the dependency earlier? During > the native build, it won't use cross-pkg-emerge, so it won't unset > PKG_CONFIG_PATH, and the wrong value will be used, assuming you've copied > that wrong value into your native environment. They cross-compiled on amd64 for arm64 stuff like libglvnd, then installed the binpkgs resulting from that on arm64, but the installed libglvnd had its .pc in /usr/lib/pkgconfig rather than /usr/lib64/pkgconfig. They said when they build packages natively (like libglvnd), things start to work again.
+1 on removing PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" from crossdev's make.conf template. It might cause some fallout for build systems that fail to use ${CHOST}-pkg-config, but that should be fixed anyway.
(In reply to Sam James from comment #8) > They cross-compiled on amd64 for arm64 stuff like libglvnd, then installed > the binpkgs resulting from that on arm64, but the installed libglvnd had its > .pc in /usr/lib/pkgconfig rather than /usr/lib64/pkgconfig. This probably warrants further investigation into how libglvnd determines the installation path for its .pc files. I doubt PKG_CONFIG_PATH has any impact on that.
libglvnd doesn't matter here, it just happened that this lib failed when I was trying to build mesa. The thing is that on normal `arm64` host the `/usr/lib/pkgconfig` doesn't even exist (as far as I can see on my arm64 machine with the same profile, but which was bootstrapped natively). The thing that failed originally was the `libwayland`, but I rebuilt it by the time I've posted in #gentoo. It's just basically that pkg-config had the dir, different to what it should, because crossdev decided to preconfigure it, while native doesn't set the PKG_CONFIG_PATH.
(In reply to Mike Gilbert from comment #10) > This probably warrants further investigation into how libglvnd determines > the installation path for its .pc files. I doubt PKG_CONFIG_PATH has any > impact on that. From meson.eclass: pkg_config_libdir = '${PKG_CONFIG_LIBDIR:-${EPREFIX}/usr/$(get_libdir)/pkgconfig}' So that should be correct. It would be wrong if the crossdev environment had the "embedded" profile, as it does by default, but aarch64-unknown-linux-gnu-emerge --info shows otherwise, unless that was changed since.
(In reply to James Le Cuirot from comment #12) > From meson.eclass: > > pkg_config_libdir = > '${PKG_CONFIG_LIBDIR:-${EPREFIX}/usr/$(get_libdir)/pkgconfig}' > > So that should be correct. It would be wrong if the crossdev environment had > the "embedded" profile, as it does by default, but > aarch64-unknown-linux-gnu-emerge --info shows otherwise, unless that was > changed since. pkg_config_libdir from the meson cross file would have no impact on where .pc files get *installed*.
This paste from your IRC conversation shows libglvnd is installed in the wrong directory (/usr/lib). https://paste.rs/KYWNj Please attach a build log that shows a library (like libglvnd) getting installed in /usr/lib on arm64. I want to see how that happens.
(In reply to Mike Gilbert from comment #13) > pkg_config_libdir from the meson cross file would have no impact on where > .pc files get *installed*. Okay, it's here: https://github.com/mesonbuild/meson/blob/156a9baab5f8b62d6a54f26fd361b493d1ddad4c/mesonbuild/modules/pkgconfig.py#L711 > pkgroot = os.path.join(_as_str(state.environment.coredata.get_option(mesonlib.OptionKey('libdir'))), 'pkgconfig') So effectively the same thing.
After chatting in #gentoo, my best guess is that LIBDIR_arm64 was unset when the libglvnd binpkg was built due to having the "embedded" profile selected. This would cause libdir to default to "lib" instead of "lib64". Really, after switching away from the "embedded" profile, all packages must be rebuilt to pick up the new profile settings.
