Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 869499 Details for
Bug 913582
sys-devel/crossdev sets PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" while the actual system expects it in /usr/lib64
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
irc-log from #gentoo
irc-log.txt (text/plain), 8.04 KB, created by
Kirill Chibisov
on 2023-09-03 17:47:09 UTC
(
hide
)
Description:
irc-log from #gentoo
Filename:
MIME Type:
Creator:
Kirill Chibisov
Created:
2023-09-03 17:47:09 UTC
Size:
8.04 KB
patch
obsolete
> 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
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 913582
: 869499 |
869501
|
869502
|
869503