| 17 Nov 2025 |
|  @kttns0ut:matrix.org left the room. | 02:30:11 |
|  Pol joined the room. | 16:20:52 |
| Pol | Hello,
I'm trying to find the issue in here: https://github.com/typst/typst/pull/7374
I succeeded to reproduce the issue at home as well.
Adding LD_LIBRARY_PATH seem to fix the issue, is it the best option we have to fix that? | 16:21:52 |
| Pol | * Hello,
Context: https://github.com/typst/typst/pull/7374
I succeeded to reproduce the issue at home as well.
Adding LD_LIBRARY_PATH seem to fix the issue, is it the best option we have to fix that? | 16:23:19 |
| Pol | I guess adding LD_LIBRARY_PATH = lib.makeLibraryPath [ pkgs.openssl ]; should be OK, do you confirm this is OK to do this? | 16:37:02 |
 Alyssa Ross | Usually I'd consider that a last resort after actually linking the library to the binary | 16:40:03 |
| Pol | OK I understand, what other option do we have here? | 16:40:30 |
| Alyssa Ross | CARGO_TARGET_${stdenv.hostPlatform.rust.cargoEnvVarTarget}_RUSTFLAGS = "-lssl" | 16:41:11 |
| Alyssa Ross | but the 100% best way to do this is to fix upstream to properly link the library | 16:41:30 |
| Pol | I will add your comment in the PR | 16:41:42 |
| Pol | Or perhaps you want to do it? | 16:41:51 |
| Alyssa Ross | you're welcome to | 16:41:56 |
| Alyssa Ross | I'm slammed today | 16:41:59 |
| Pol | Same... | 16:42:10 |
| Pol | I'll do it, thanks for the tips | 16:42:14 |
| Alyssa Ross | sometimes whatever crate links the library will have a Cargo feature option to control whether it dlopens or properly links | 16:42:17 |
| 18 Nov 2025 |
|  QuadRadical (Ping) changed their profile picture. | 01:59:42 |
| 19 Nov 2025 |
|  7karni joined the room. | 12:07:30 |
| 20 Nov 2025 |
|  John joined the room. | 04:58:48 |
 dotlambda | Is there some way of running cargo build --target=wasm32-wasip1 while building a package for x86_64-linux?
https://github.com/NixOS/nixpkgs/pull/463349 | 21:19:25 |
 rosssmyth | Not that I am aware of. You may be able to hack something together with fastCross. But the way the rustc derivation is setup right now makes it hard to just compile a sysroot for a target. | 21:38:12 |
| rosssmyth | * Not that I am aware of. You may be able to hack something together with fastCross. But the way the rustc derivation is setup right now makes it hard to just compile a sysroot for a target without structuring all of your Nixpkgs instance around it. | 21:38:35 |
| rosssmyth | You may be able to do something funny like setting the platforms to a wasi and require people to use pkgsCross.wasi32. But I have no idea what the state of compiling for wasi32 is or if that would work. Would be annoying for end-users though. | 21:41:41 |
 Sandro 🐧 | mitmproxy-linux is cross compiling without anything extra to something wasm | 21:46:52 |
| Sandro 🐧 | *ebpf not wasm | 21:49:53 |
| Sandro 🐧 | your target is missing here https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/rustc.nix#L158-L161 though | 21:50:09 |
| Sandro 🐧 | maybe this hint https://github.com/NixOS/nixpkgs/blob/master/lib/systems/default.nix#L504 helps | 21:51:07 |
| dotlambda | I would hope that adding something like pkgsCross.wasi32.buildPackages.rustc does the trick | 22:03:08 |
| rosssmyth | Probably will, but that has the downside of instantiating a whole other nixpkgs | 22:03:38 |
| dotlambda | pkgsCross.wasi32 is also used to build Firefox | 22:04:06 |
