| 21 Sep 2025 |
 matthewcroughan | * Ah okay I see, I'm producing a linux kernel with vmlinuz.efi as the target, which isn't supported by qemu on aarch64 I guess | 00:17:38 |
| matthewcroughan | whereas for musl I'm just setting crossSystem, here I'm setting nixpkgs.hostPlatform and some linux-kernel args leaked in from my other experiments | 00:18:00 |
 Tristan Ross | In reply to @matthewcroughan:defenestrate.it
Ah okay I see, I'm producing a linux kernel with vmlinuz.efi as the target, which isn't supported by qemu on arm64 I guess Just do an uncompressed kernel | 01:12:34 |
| matthewcroughan | I did, that worked fine | 01:12:43 |
| matthewcroughan | I have an llvm, llvm-musl, llvm nixos config and the minimal nix files to change that now | 01:12:57 |
| matthewcroughan | it's not too much, but it was a lot of research | 01:13:34 |
| matthewcroughan | when I get my m2 ultra I'm gonna put up some CI on github for it | 01:15:00 |
|  Jannik Wolff joined the room. | 08:04:08 |
 SomeoneSerge (back on matrix) | py_mod.find_installation() with strictDeps = true seems to pick up meson's interpreter, rather than the python-env wrapper from buildInputs | 16:47:51 |
| SomeoneSerge (back on matrix) | FWIW I tried to trace the chain from find_installation to find_program in hopes to understand how does one even specify which platform's python they want, and my conclusion was "fuck if I know" | 16:48:54 |
| SomeoneSerge (back on matrix) | mesonbuild matrix says it's supposed to look for the host python, so something must be wrong on our side | 21:52:00 |
 rosssmyth | What are you working on? If this is running at build-time it will probably sniff around PATH and find the meson interpreter or something. Add python to depsBuildBuild or nativeBuildInputs. buildInputs is for a python interpreter than runs on the host machine the final executable runs on, so at build time it will not find it. | 22:14:16 |
| SomeoneSerge (back on matrix) |
this is running at build-time
It's not, it's for the host. The find_installation method is, according to upstream chat, for the host. It's a meson-packaged gtk app written in python o_0. Native/strictDeps=false works and builds fine, but like why would I want strictDeps=false this is cringe
| 23:44:02 |
| SomeoneSerge (back on matrix) | *
this is running at build-time
It's not, it's for the host. The find_installation method is, according to upstream chat, for the host. It's a meson-packaged (nb: not meson-python) gtk app written in python o_0. Native/strictDeps=false works and builds fine, but like why would I want strictDeps=false this is cringe
| 23:44:53 |
| 22 Sep 2025 |
| SomeoneSerge (back on matrix) | Mhmmm update: it's basically the same disaster as cmake, they look to run python from PATH on BUILD, but want its sysconfig to return cross stuff | 01:11:07 |
| SomeoneSerge (back on matrix) | So I guess nvm it's meant to be broken | 01:11:21 |
| rosssmyth | Maybe. You might be able to add a path to one of these options https://mesonbuild.com/Builtin-options.html#python-module but who knows. If not then patching your cross-file may be required with substituteInPlace or replaceVars | 01:28:56 |
| rosssmyth | * Maybe. You might be able to add a path to one of these options https://mesonbuild.com/Builtin-options.html#python-module but who knows. If not then patching your cross-file may be required with substituteInPlace or replaceVars | 01:29:03 |
| 23 Sep 2025 |
|  estrange joined the room. | 00:18:31 |
|  kenji changed their display name from a-kenji to kenji. | 10:42:22 |
|  @jolman:matrix.org left the room. | 20:12:34 |
|  @freexploit:trafkin.com | 20:37:20 |
| @freexploit:trafkin.com | 20:37:38 |
| @freexploit:trafkin.com left the room. | 20:38:28 |
| 24 Sep 2025 |
| matthewcroughan | What should the correct solution be for this instead of relying on glibcPkgs?
...
netbsd = super.netbsd.overrideScope (
_final: prev: {
compat = prev.compat.overrideAttrs (old: { makeFlags = old.makeFlags ++ [ "OBJCOPY=${glibcPkgs.binutils}/bin/strip" ]; });
}
);
...
| 14:37:20 |
| matthewcroughan | this turned out to not do anything | 14:38:54 |
| 25 Sep 2025 |
| matthewcroughan | Anyone got any guesses as to why this might be happening then?
[16/19] Building C object CMakeFiles/zig2.dir/compiler_rt.c.o
[17/19] Building C object CMakeFiles/zig2.dir/zig2.c.o
[18/19] Linking CXX executable zig2
FAILED: [code=1] zig2
: && /nix/store/zxfq7vsw55hhjnfm841k1x5x2fmsqmni-aarch64-unknown-linux-musl-clang-wrapper-21.1.1/bin/aarch64-unknown-linux-musl-clang++ -O3 -DNDEBUG -Wl,-z,stack-size=0x10000000 CMakeFiles/zig2.dir/zig2.c.o CMakeFiles/zig2.dir/compiler_rt.>
aarch64-unknown-linux-musl-ld: error: undefined symbol: llvm::sys::getProcessTriple()
>>> referenced by zig_llvm-ar.cpp
>>> zig_llvm-ar.cpp.o:(llvm_ar_main(int, char**, llvm::ToolContext const&)) in archive zigcpp/libzigcpp.a
>>> referenced by Driver.cpp.o:(lld::wasm::(anonymous namespace)::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>)) in archive /nix/store/j0m3sirlqygwaq6v4jhjdbardc503a5d-lld-aarch64-unknown-linux-musl-20.1.8-lib/lib/liblldWasm.a
>>> referenced by DriverUtils.cpp.o:(lld::elf::ELFOptTable::parse(lld::elf::Ctx&, llvm::ArrayRef<char const*>)) in archive /nix/store/j0m3sirlqygwaq6v4jhjdbardc503a5d-lld-aarch64-unknown-linux-musl-20.1.8-lib/lib/liblldELF.a
>>> referenced 5 more times
| 15:01:48 |
| matthewcroughan | oh yeah.. why is it using ld and not lld | 15:45:25 |
| matthewcroughan | Tristan Ross: | 15:46:25 |
| Tristan Ross | Huh, idk | 15:48:23 |
