00:18 <chadmed> ffs why is $(get_libdir) returning lib64 in crossdev when the libs get installed to lib

00:31 <chaos_princess> which package

00:33 <chadmed> gcc stage 1

00:33 <chadmed> its also pulling aarch64-unknown-linux-gnu into ${ED} so i think its getting confused with the host portage?

00:34 <chaos_princess> if it is from crossdev itself then i think lib64 is right

00:35 <chadmed> the files it's trying to stat are in ${ED}/usr/lib though so something is dodgy

00:36 <chadmed> is it expecting USE=multilib or something

01:46 <sam_> oh not this bs again..

02:04 <chadmed> was it something i said :p

02:06 <sam_> you know I wouldn't say that about something a person said :)

02:06 <sam_> more that the bug is really irritating

02:06 <sam_> first there's bug 794181

02:06 <sam_> but i was thinking of bug 908455

02:07 <chadmed> yeah im hitting that second one

02:07 <chadmed> let me try with --abis 'amd64 x86'

02:07 <sam_> (it's the same root cause, I think, but what I don't get is why it ever worked)

02:08 <sam_> oh no I think I know why lmao

02:08 <sam_> it must have been in one of my many toolchain.eclass cleanups

02:08 <sam_> where I added || die

02:08 <sam_> and it never worked, just nobody noticed

02:08 <chadmed> lmfao so previously it was just silently not doing anything

02:08 <sam_> yep

02:09 <chadmed> well judging by random emails i sometimes receive i feel like we have way more users than we think

02:09 <chadmed> so this is gonna have to work properly :p

02:09 <chadmed> yup still fails with --abis 'amd64 x86' smdh

02:10 <sam_> I think a glob is good enough there

02:10 <sam_> better than now, anyway

02:10 <sam_> can you test it and send a patch?

02:11 <chadmed> test what?

02:12 <sam_> glob instead of get_libdir?

02:12 <sam_> lib*

02:13 <chadmed> oh right yeah patch the eclass one sec

02:14 <sam_> also, frankly

02:14 <sam_> i think the fight for non-flat libdir is over

02:14 <sam_> we tried it with riscv

02:14 <sam_> it didnt work

02:14 <sam_> way too much shit broke

02:14 <sam_> ($(get_libdir) is useful especially where you have like, lib/libFUCKMEABI)

02:15 <chadmed> i didnt even realise we werent symlinking lib to lib64 tbh

02:32 <chadmed> lfg that worked

02:34 <chadmed> oh this is completely fucked and broken

02:34 <chadmed> it unions the host portage but does not respect package.env are you serious

02:35 <chadmed> checking for x86_64-unknown-linux-gnu-gcc... clang -m64 -fuse-ld=lld -Wl,--as-needed -Wl,-O3 -Wl,-zrelro -Wl,-zpack-relative-relocs -Wl,--undefined-version

02:35 <chadmed> just.... why

03:23 <chadmed> none of this has been tested by anyone not on a stock standard amd64 gentoo machine has it far out

03:23 <chadmed> glibc cant find prctl.h because its looking at the host headers -.-

03:24 <chadmed> we cannot use this as a solution for installing thunks its deranged

03:24 <chadmed> at least not in the state its in

03:29 <chadmed> if clang doesnt work at all then we can either build them on an amd64 machine and host them somewhere or just pinch them out of the fedora rpm

06:20 <chaos_princess> Are you trying to make clang work?

06:22 <chadmed> no im just trying to get crossdev to set up amd64/gcc

06:23 <chaos_princess> And it is failing?

06:23 <chadmed> issue seems to be that amd64 glibc expects <asm/prctl.h> in /usr/include/ which is not the case for arm64 and it is not looking in /usr/${CHOST}/usr/include/

06:24 <chaos_princess> For me setting up x86 and amd64 gccs was as simple as just running the crossdev commands so i am kinda confused as to what went wrong with yours

06:24 <chadmed> yeah idk

06:29 <chadmed> could be crossdev being intolerant of clang as the host system compiler but ive got my gcc env override set for cross-x86_64-unknown-linux-gnu/* (and an explicit amd64 one for glibc) and it still explodes

06:38 <chadmed> i filed a bug about it, it does seem to be related to ^

06:38 <chadmed> https://bugs.gentoo.org/938482

06:39 <chadmed> i might need something special in env

07:26 <sam_> i think explicitly setting CC confuses crossdev

10:03 <chadmed> yeah :/

10:03 <chadmed> i tried putting CC="" and unset CC (and the rest of the toolchain) in an env but it did nothing

10:07 <sam_> I'm not sure unset works in env

10:07 <sam_> anyway that's a known issue I'm not yet sure how to fix

10:14 <chadmed> hmmm yeah okay

10:15 <chadmed> in any case i dont think we can really ship anything that hard depends on this working tbh

10:16 <chadmed> so i think at least in the short term we should probably just do surgery on the fedora rpm with the thunklibs in it

10:17 <chadmed> or better yet just pinch the rootfs wholesale if it already has the thunks loaded in

10:18 <chadmed> anyway building the kernel witl clang works again, it was just CONFIG_DEBUG_INFO_BTF

11:09 <u154ss> @all maybe I have overseen something. Using Debian, since asahi-6.10.3-1, when I do a kernel build (make -j8 LLVM=-17 OR LLVM=-18 bindeb-pkg) initrd is not being built. I have changed nothing in my .config. Anyone else experiencing this? asahi-6.10.3-1 works, i.e. initrd builds.

21:05 <cy8aer> @irc_oftc_u154ss:g3la.de: Still no problems. Beware that the initrd building is done at installation time with a postinstall hook. "/etc/kernel/postinst.d/initramfs-tools". You may try to build the initrd "by hand" or via "update-initramfs" to see if there are problems on building the intrd

21:09 <cy8aer> and for orientation: these are my main config diffs to default: https://git.g3la.de/repos/m1-debian/src/branch/baer/config.txt