<qyliss>
I'd love to be able to have power9-based build infra but with x86_64 emulation being so slow currently it's infeasibl/e
cole-h has quit [Quit: Goodbye]
<IdleBot_4fae1f80>
qyliss: cross-compilation + custom substituters to accept cross instead of native could help, maybe?
<qyliss>
hmm, would that work?
<IdleBot_4fae1f80>
Anyway, whoever can exploit x86_64 horrors, can probably also exploit wl_roots memory handling being more tricky than is a norm for C code
<qyliss>
I don't really know how substituters work
<qyliss>
that's true although it would mean I could support more architectures with less hardware
<qyliss>
will be a while before the program I linked goes anywhere anyway, if it ever does
jpds_ has quit [Remote host closed the connection]
<qyliss>
but it's nice to see it happening, because it might be ready for us when we need it.
jpds_ has joined #spectrum
<IdleBot_4fae1f80>
Does it even matter how substituters in Nix work today? By the time you can afford supporting people who will not just nix-build themselves (SpectrumOS does not seem to have a reason for _large_ divergence with NixOS), something can change in preparation for CA store
<qyliss>
excellent point
<IdleBot_4fae1f80>
And you cannot support an arch without an active user there, and once you have multi-arch users you have a good chance to ask them write a script for making cross-compiled stuff usable in place of native
<IdleBot_4fae1f80>
Most likely it is already there because of some Nix-on-handheld users
<IdleBot_4fae1f80>
And if there are no users but you need to finish the milestone… well, make it easy to mix cross-compiled stuff, emulated-compiled-stuff and NixOS Hydra stuff, and build as much as practical.
<IdleBot_4fae1f80>
The most expensive package to build, Chromium, has problems different from being built on x86_64 anyway. Like partially malicious upstream
<qyliss>
there's no milestone for this -- just stuff I'm thinking of
<qyliss>
I won't be doing anything about it any time soon.
<IdleBot_4fae1f80>
I guess binary translation is also nice to run old Flash binary inside a sandbox on POWER9…
jpds_ has quit [Remote host closed the connection]
jpds_ has joined #spectrum
jpds_ has quit [Remote host closed the connection]
jpds_ has joined #spectrum
cole-h has joined #spectrum
jpds_ is now known as jpds
jpds has quit [Remote host closed the connection]
jpds_ has joined #spectrum
jpds_ is now known as jpds
<puck>
<qyliss> Promising idea: https://github.com/shawnanastasio/retrec <- a thing that could be reasonable to do, assuming no dynamic code generation, is to decompile the x86_64 code into llvm ir, then retarget it; if the architectures are similar enough, this might actually be doable reasonably
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #spectrum
jpds has quit [Ping timeout: 240 seconds]
jpds has joined #spectrum
cole-h has quit [Ping timeout: 246 seconds]
cation21- has joined #spectrum
cation21 has quit [Ping timeout: 256 seconds]
cation21- is now known as cation21
jpds has quit [Remote host closed the connection]
jpds has joined #spectrum
<zgrep>
puck: Aren't there several things that raise binaries to LLVM IR? Though not all are completely open source, or something else license-related.
<puck>
possibly, yeah; mctoll i think was the primory one i was thinking of, though