ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
<chaos_princess>
Probably libc++ or something in gcc stage 2
chadmed_ has joined #asahi-alt
KxCORP5894000 has quit [Quit: Bye!]
KxCORP5894000 has joined #asahi-alt
<chadmed_>
it was amd64 glibc, didnt realise you reset CC after x86 glibc was built :p
<chadmed_>
let's see now...
<chadmed_>
urgh now its going to be libstdc++ in gcc stage 2 isnt it...
<chadmed_>
this is so fucking stupid why cant we just have bin thunks
<chadmed_>
seems to be passing the lib build with no toolchain overrides but idk what this is going to do at runtime...
<chadmed_>
right looks like gcc stage 2 just silently dropped libstdc++
<chadmed_>
var/tmp/portage/app-emulation/FEX-2408/work/FEX-FEX-2408/ThunkLibs/GuestLibs/../libVDSO/Types.h:2:10: fatal error: 'cstdint' file not found
<runxiyu>
i'm running Jared's gentoo install, and everything seems great, though i would want to ask whether people had luck with the openrc stage3's
<runxiyu>
i'm not familiar with initramfs stuff other than arch's mkinitcpio
<chadmed_>
i use openrc
<chadmed_>
its fine everything works
<chadmed_>
no nvm libstdc++ does exist because i can compile cpp code with the toolchain, the fex ebuild just doesnt know where it is or something
chadmed_ has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
aead has quit [Remote host closed the connection]
aead has joined #asahi-alt
Juest is now known as Guest1590
Juest has joined #asahi-alt
Guest1590 has quit [Ping timeout: 480 seconds]
<runxiyu>
ah nice
<runxiyu>
I never did Asahi Gentoo before and I'm a bit scared (lol) so I'm following Jared's systemd guide for now
<runxiyu>
I'll switch it next reinstall when I get familiar enough with the initramfs-making process
chadmed_ has joined #asahi-alt
<chadmed_>
runxiyu: jared's guide is now really outdated as we have moved to a new method where i publish uefi bootable installcds so if it still works its only by fluke
<chadmed_>
when you reinstall please follow the guide on the asahi github wiki
<runxiyu>
Oops
<runxiyu>
Uhh I'm still compiling clang
<runxiyu>
Haven't even gotten to Linux
<runxiyu>
So I'll go check the official one
chadmed_ has quit [Quit: Page closed]
opticron has quit [Read error: Connection reset by peer]
opticron has joined #asahi-alt
<runxiyu>
chadmed: Could I have the checksum for install-arm64-asahi-latest.iso on your website?
<runxiyu>
Also, "From here, you can simply follow the Gentoo Handbook for amd64, stopping only when it is time to install a kernel." almost made me unpack an amd64 stage3 ._.
<runxiyu>
Ah, thanks!
<chaos_princess>
So, thunks use kind of an insane build process where they use host headers for compiling x86 code. And i guess llvm systems install them in a different place to gcc ones
<chaos_princess>
Where even _is_ cstdint on a llvm system?
<chadmed>
yeah i assume thats whats going on because thunkgen is just exploding in some random place and then throwing "cant find blah blah blah header" errors
<chadmed>
but like
<chadmed>
i dont use libcxx
<chadmed>
usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/ has my sepples headers?
<chadmed>
and clang knows about it because i can compile c++ code just fine
<chaos_princess>
Can you manually run the failing thunkgen command and add --verbose to it?
<chaos_princess>
(thunkgen is a clang plugin(?) and should accept clang flags)
<chadmed>
yeah i can just grab the invocation that failed from the build log
<chaos_princess>
there should be some way to make it print what places it searches for headers in
<chadmed>
basic program that includes cstdio and calls printf, compiled fine and runs (of course)
<chaos_princess>
can you grep for gcc inside /etc/clang
<chadmed>
just the standard stuff gentoo installs, the only non comment is --gcc-install-dir="/usr/lib/gcc/aarch64-unknown-linux-gnu/14"
<chaos_princess>
Ok, and now take that thing and add it to tunkgen flags
<chadmed>
it worked
<chaos_princess>
Well, now to find out how to do it automatically i guess
<chaos_princess>
which file was the flag in?
<chadmed>
etc/clang/gentoo-gcc-install.cfg
<chadmed>
surely we can just patch the flag into the relevant cmakelists file
<chaos_princess>
Yes
<chadmed>
i have a bunch of other overrides locally that made it work here that _should_ keep working on pure gcc systems (just explicitly specifying flags and such instead of using whatever portage gives us)
<chaos_princess>
Well, we can't patch the flag itself, since it is dependent on gcc version, but we can fish it out of that file and pass it that way
<chadmed>
yeah
zerdox_ has joined #asahi-alt
<chaos_princess>
Which other overrides did you have to pass?
<chadmed>
does unconditionally passing in the flag break anything then
<chadmed>
id assume not if clang is useable on these systems
<chaos_princess>
idk, fired off the compiles on my gcc system, we will know in like 15 mins
<chadmed>
ezpz
<chadmed>
last trick if we want to tackle it would be amd64 mesa but meson's cross compilation system is thoroughly deranged and i dont want to touch it
<chadmed>
and also hopefully the asahi mesa just ends up vendored by either the fedora rootfs or a fex-blessed one
<chaos_princess>
for rootfs, i kinda want to build a "steam-nano" one. Just enough libraries to start steam, and then use everything from steam runtime
<chadmed>
that could be cool
<chadmed>
also we need to install the binfmt handlers
<chaos_princess>
not yet
<chaos_princess>
krun installs binfmt handlers in the nested vm, but on host we need krun's launcher handlers
<chaos_princess>
and i do not want to "ship" krun yet
<chadmed>
yeah true and nor do i its a mess
zerdox has joined #asahi-alt
<chaos_princess>
confirming that it all builds on gcc
<chadmed>
okay sick ill yeet the if block
<chadmed>
tomorrow now though its almost 11pm
<j`ey>
chadmed: so in an hour?
<chadmed>
im hopiing to be asleep before the top of the next hour :p
<chadmed>
also the manifest for sommelier was wrong and i updated it
<chaos_princess>
that might actually be bad, they could be generating that tarball on the fly and we might need to mirror it
<chadmed>
hmm yeah the size was pretty different...
<chadmed>
google moment
n3ph has joined #asahi-alt
<sam_>
you should always diff the tarballs in that case
<sam_>
not just regen
<chaos_princess>
ill mirror the sommelier subtree to gh