| 12 Jan 2025 |
 lzcunt | Heyy here's an update on this: I hit a bug in mlibc hopefully soon to be fixed upstream, static musl is still broken and I don't know what to do about it | 11:09:27 |
| lzcunt | It's seemingly the same issue that broke the mlibc static gcc-nolibc build but the same fix doesn't work | 11:09:54 |
| lzcunt | * It's seemingly the same issue that broke the mlibc static gcc-nolibc build but the same fix doesn't work (disabling some options and autoconf | 11:10:24 |
| lzcunt | during link tests for libstdcxx it tries building something simple and statically linking but there is no libc to link because it's nolibc, but that should be fixed by --disable-hosted-libstdcxx (and is fixed for mlibc but not for musl | 11:12:13 |
|  tristan.a joined the room. | 14:12:34 |
 Alexandros Liarokapis | I am using buildRustPackage to cross-compile a rust package. I need to use a darwin CoreFramework in the build script but adding any of the frameworks in any of the nativeBuildInputs/buildInputs/LD_LIBRARY_PATH etc doesn't seem to work | 16:27:29 |
| Alexandros Liarokapis | Something weird going on probably offset related | 17:39:19 |
 Artturin | We need to see the code, errors, and expression. | 18:25:05 |
| Alexandros Liarokapis | Nevermind it is the fact that i use a cursed custom stdenv because i cross compile for none platform and use arm's toolchain | 19:10:21 |
| 14 Jan 2025 |
 DavHau | Cross compilation of numpy 2 is broken, erroring out with Can not run test applications in this cross environment. despite mesonEmulatorHook being used.
It fails executing this instruction here: https://github.com/numpy/numpy/blob/e7a123b2d3eca9897843791dd698c1803d9a39c2/numpy/_core/meson.build#L408
Any ideas why it doesn't want to use the emulator?
| 01:44:32 |
 Colin | In reply to @hsngrmpf:matrix.org
Cross compilation of numpy 2 is broken, erroring out with Can not run test applications in this cross environment. despite mesonEmulatorHook being used.
It fails executing this instruction here: https://github.com/numpy/numpy/blob/e7a123b2d3eca9897843791dd698c1803d9a39c2/numpy/_core/meson.build#L408
Any ideas why it doesn't want to use the emulator?
there was a fix for this in staging that hasn't reached master yet. take a look here? | 01:53:42 |
| Colin | https://github.com/nixos/nixpkgs/pull/368479 | 01:53:45 |
| DavHau | 🤦♂️Why did the previous workaround not work? Anyways, thanks for sparing me hours of debugging. I should learn how to search the issue tracker I guess. | 01:58:22 |
| 15 Jan 2025 |
|  olographix joined the room. | 15:31:03 |
|  SomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (utc+3) to SomeoneSerge. | 19:02:17 |
|  Slushee joined the room. | 20:02:55 |
| 16 Jan 2025 |
|  FliegendeWurst joined the room. | 09:37:03 |
| 20 Jan 2025 |
| FliegendeWurst | I'm building a library with Python bindings (syndication-domination), and I use (python3Packages.python.pythonOnBuildForHost.withPackages (ps: [ps.pybind11])) to create a cpython .so module.
Why is the resulting file called syndom.cpython-312-x86_64-linux-gnu.so when cross-compiling Linux x64->aarch64?
(It is a proper "ARM aarch64" so according to file)
Should I just handle it as a quirk of this particular package and rename it, or should I patch pybind11 instead? | 12:56:12 |
| lzcunt | I can't seem to get the regression in https://github.com/NixOS/nixpkgs/pull/370683 to be fixed, does it make sense to simply guard the langCC changes to only mlibc platforms? (musl fails, mlibc which is added in a different PR doesn't) | 18:05:54 |
| lzcunt | CC Tristan Ross (not sure if you'd enjoy a ping so hopefully this doesn't ping): not sure if this works with LLVM libc but this patch might also be needed for LLVM libc on a gcc toolchain. If you ever try building llvm libc with gcc, could you please see if this is needed or works or breaks anything? | 18:10:18 |
 Tristan Ross | In reply to @sananatheskenana:matrix.org
CC Tristan Ross (not sure if you'd enjoy a ping so hopefully this doesn't ping): not sure if this works with LLVM libc but this patch might also be needed for LLVM libc on a gcc toolchain. If you ever try building llvm libc with gcc, could you please see if this is needed or works or breaks anything? GCC is broken with LLVM libc because it doesn't support [[gnu::naked]] on certain architectures lol. | 18:18:26 |
| Tristan Ross | Building LLVM libc pretty much is only supported with pkgsLLVM | 18:19:53 |
| lzcunt | Ok then, what do you reckon about only enabling langCC for mlibc because it needs it but seemingly that option breaks musl? (libstdc++ linker tests fail with musl) I don't think fixing an issue with musl which I don't know a lot about is in scope of my mlibc adventures | 18:22:44 |
| Tristan Ross | I think it's also breaking pkgsLLVMLibc outside of pkgsLLVM | 18:23:33 |
| Tristan Ross | OpenSSL is getting an infinite recursion in curl inside of cmake | 18:23:59 |
| lzcunt | I'll try looking at it tomorrow possibly, I has my own share of almost unfixable infinite recursion. I think I encountered a similar issue with openssl and zlib in python and it was python's weird dependency memes that needed special casing for openssl | 18:26:15 |
| lzcunt | * I'll try looking at it tomorrow possibly, I had my own share of almost unfixable infinite recursion. I think I encountered a similar issue with openssl and zlib in python and it was python's weird dependency memes that needed special casing for openssl | 18:26:28 |
| Tristan Ross | Yeah, the problem seems to be reading stdenv.cc.is* | 18:28:07 |
| lzcunt | oof | 18:28:42 |
| lzcunt | I'll close the langCC PR and add that commit (gated for only mlibc) to the mlibc PR, and leave a small comment for future reference on it | 18:30:53 |
