kchibisov Did something happen to the way cross works? I basically did what I was doing years before, and I've noticed that lots of stuff fail to find deps when pulling binary packages. sam_ could you be more specific? nothing's really changed there kchibisov Like for example, if I cross build wayland, then install that package, nothing will be able to find it, unless I rebuild it on the host. mstrgecko tdr: it was like this when i first got thecard, ihad this issue. i came here, wegot it working by changing some config, and it worked. in the process of arecent `emerge @world` i used dispatch-conf to approve changes for new stuff, and i think, accidentaly reverted the wifi fix in the process. .. :( kchibisov sam_: it's just pkgconfig/cmake will fail to find everything I pull from the cross. sam_ (some commands + output would be helpful) kchibisov sam_: I mean, emerge -a sway; will fail to find egl lib. kchibisov even though, I have mesa. sam_ surely not actually `emerge` though, it'd be ${CHOST}-emerge, and it'd be useful to see the actual log of the failure to see why the detection fails sam_ i just mean it's easier to see real things, not guesses/paraphrases kchibisov https://paste.rs/vNqyF kchibisov That's example with mesa. kchibisov You can see that libglvnd wasn't found, when it's installed and portage knows that it's installed. sam_ ah, so you've cross-compiled from another machine for arm64, then installed the result, and now suspect deps are missing. right. nothing in that log mentions binaries though? so where does the "when pulling binary packages" come in? sam_ (also nothing in the log shows that it knows libglvnd is installed) sam_ or, I guess given that emerge didn't queue it tdr mstrgecko, rollback is mentioned in its man page, i dont see how its done sam_ but if it *is* actually installed, we need to see /var/tmp/portage/media-libs/me sa-23.2.0_rc2/work/mesa-23.2.0-rc2-.arm64/meson-logs/meson-log.txt kchibisov sam_: the mesa was cross compiled on other machine and installed as a binary package before. kchibisov Then I try to build something on that arm64 machine and it can't find mesa. tt_1 mesa is a bit broken if cross-compiled negril adelks: read https://wiki.gentoo.org/wiki/Project:Qt/Policies re qt USE-Flags kchibisov tt_1: it happened to libwayland as well. tt_1 but here it is libglvnd which cannot be found, right? kchibisov tt_1: yes, because it was also installed as a binary package before. sam_ kchibisov: show me meson-log.txt? adelks thanks negril tt_1 hmm tdr mstrgecko, look inside /etc/dispatch-conf.conf for archive-dir tt_1 malformed pkgconf file? sam_ I also don't see how it being a binary package could make any difference unless the image actually varies (which you could diff) negril kchibisov: mesa has nothing to do with egl since libglvnd tt_1 I do a lot of cross compile stuff, mesa as well kchibisov negril: it's just example, I got failure with wayland initially. kchibisov I just already rebuild some stuff. tt_1 so I need hard facts: emerge -pv libglvnd and emerge -pv mesa, and emerge --info would be helpfull sam_ still need meson-log.txt first tt_1 yeah, meson logs for sam_ who will devour them happily :) kchibisov https://paste.rs/VPVSx sam_ env[PKG_CONFIG_LIBDIR]: /usr/lib64/pkgconfig sam_ isn't it /usr/lib/pkgconfig on arm64? sam_ oh no it's not sam_ equery f libglvnd please tt_1 oh, it is an rc2 tt_1 there have been bugs in mesa in the past with pkgconf files negril "../mesa-23.2.0-rc2/meson.build:1820:14: ERROR: Dependency "libglvnd" not found, tried pkgconfig and cmake" tt_1 if you give me emerge -pv mesa I can reproduce kchibisov tt_1: the thing is that I think it only breaks with the way I have it installed. tt_1 maybe kchibisov If you compile everything on arm64 it's ok. tt_1 still emerge -pv mesa please sam_ [18:18:35] <+sam_> equery f libglvnd please sam_ can everyone just wait a second until i'm done with a line of inquiry sam_ before we dive into guesses tt_1 ok :) kchibisov Yeah, I'm on that. negril kchibisov: wgetpaste -c "equery f libglvnd" kchibisov negril: I know how to paste to paste.bin. negril just trying to make it quicker :) tt_1 is equery working for cross-compiled packages? sam_ why wouldn't it sam_ please read the full context kchibisov https://paste.rs/KYWNj sam_ [18:12:47] <+sam_> ah, so you've cross-compiled from another machine for arm64, then installed the result, and now suspect deps are missing. right. nothing in that log mentions binaries though? so where does the "when pulling binary packages" come in? * toralf wonders about a useful number for --backtrack=, is 100 ok or rather 200 or only 50 ? sam_ kchibisov: if you move those pkgconfig files from lib->lib64, does Mesa work? negril reminds me of Bug 772380 :] willikins negril: https://bugs.gentoo.org/772380 "sys-apps/portage: implement an ebuild generator for "ebins" which are inspired by paludis "pbins" and IUSE_RUNTIME (GLEP 62)"; Portage Development, Binary packages support; CONF; zmedico:dev-portage sam_ please sam_ that would make absolutely no difference here kchibisov sam_: I think it should. sam_ this is most curious kchibisov I can guess based on wayland stuff being there and that's the only thing that failed and works now. kchibisov But I'll copy and ensure anyway. kchibisov it's just, the device is slow so you have to wait™ negril you could symlink kchibisov The slow part comes from the emerge mesa. kchibisov sam_: it does work and mesa starts to build now. sam_ in any case this is interesting indeed sam_ we'll have to examine it on the machine where you do cross, I assume (which is good as this is faster ;)) kchibisov I could say that cross machine is weird a bit, given that it's in a amd64 chroot. kchibisov But the make.conf and the way cross was setup in chroot is no different to what it. kchibisov Hm, I think I know the issue. kchibisov crossdev set PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" kchibisov And I think it never set it before. sam_ crossdev seems to have set that since fea0d8585c4583cab3f8413c58a201dba1993320 sam_ in 2008 kchibisov Where cross toolchain was generated with crossdev --stable -t aarch64-unknown-linux-gnu kchibisov But the actual system wants it in lib64. sam_ but I too have: PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" sam_ can you file a bug please? sam_ there's no way that's right kchibisov Both system use the [15] default/linux/arm64/17.0/systemd/merged-usr (stable) * negril sam_: do a ls /usr/lib*/pkgconfig sam_ locally or what negril yes sam_ i only have one thing in there on an arm64 machine sam_ passwdqc! sam_ naughty negril https://bpa.st/KY7CG kchibisov My other arm64 machine which was entirely built from scratch doesn't have /usr/lib/pkgconfig. negril I have both on ~amd64 sam_ yeah, this is definitely wrong kchibisov only /usr/lib64/pkgconfig. kchibisov I guess that's also part of the reason cross toolchain fails a lot. negril https://bpa.st/D7QMS https://bpa.st/MJNRM kchibisov Because I got like lots of failures due to cross stuff fail to find deps. negril That being said I have ABI_X86_32 stuff kchibisov But I was too tired to invistigate it then... negril does arm have multilib? sam_ i wonder if cross-pkg-config (which crossdev installs) is being shadowed/not picked up with merged-usr or something