| 13 Apr 2025 |
|  mao zedong changed their display name from zekeriya öz to nixosfanboy. | 08:25:19 |
| mao zedong changed their profile picture. | 08:26:48 |
| 15 Apr 2025 |
|  Willow joined the room. | 18:23:26 |
| Willow | I'm trying to cross compile a rust binary from x86_64-linux to windows using Nix. I built a flake (https://github.com/Kek5chen/syrillian/blob/0e2aa5f65039eddf9a790c76f9f7538c05e2ad50/flake.nix#L56)
The rust dependencies need some c libraries that also need to be compiled.
Here's the issue:
syrillian-x86_64-w64-mingw32> error: linking with `/nix/store/b5bkhvxw5wm7mbqfvls6x1qc9jiqkfp5-x86_64-w64-mingw32-gcc-wrapper-14-20241116/bin/x86_64-w64-mingw32-cc` failed: exit status: 1
syrillian-x86_64-w64-mingw32> |
.....
syrillian-x86_64-w64-mingw32> = note: some arguments are omitted. use `--verbose` to show all linker arguments
syrillian-x86_64-w64-mingw32> = note: /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x5c): undefined reference to `_MCF_tls_key_new'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x9b): undefined reference to `_MCF_thread_self'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0xb4): undefined reference to `__MCF_tls_table_get'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x110): undefined reference to `_MCF_once_wait_slow'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x126): undefined reference to `__MCF_gthr_call_once_seh_take_over'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x16b): undefined reference to `_MCF_mutex_unlock_slow'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x1a6): undefined reference to `__MCF_tls_table_xset'
syrillian-x86_64-w64-mingw32> /nix/store/z2h4v7d7mrslcnxmpq195czvjiwd9vgv-x86_64-w64-mingw32-binutils-2.43.1/bin/x86_64-w64-mingw32-ld: /nix/store/1nyv07jn5hj04f5j10gwzyafh07fr2p6-x86_64-w64-mingw32-gcc-14-20241116/lib/gcc/x86_64-w64-mingw32/14.2.1/libgcc_eh.a(emutls.o):(.text+0x2c1): undefined reference to `_MCF_mutex_lock_slow'
syrillian-x86_64-w64-mingw32> collect2: error: ld returned 1 exit status
I can post the full invocation on gist.
| 18:27:57 |
 @curid:matrix.org | what pulls openssl-sys? | 18:32:57 |
| Willow | i don't understand the question? | 18:33:21 |
| Willow | * i don't understand the question, could you rephrase? | 18:33:28 |
| Willow | I think assimp needs it as a built time dependency | 18:34:49 |
| @curid:matrix.org | I don't see anything in the dependency list that would need it https://crates.io/crates/scyllax/0.2.1/dependencies | 18:35:00 |
| Willow | * I think russimp needs it as a built time dependency | 18:35:02 |
| Willow | that's not my tool. | 18:35:17 |
| Willow | https://crates.io/crates/syrillian/0.1.2/dependencies
which depends on
https://crates.io/crates/russimp/3.2.0/dependencies
which depends on
https://crates.io/crates/russimp-sys/2.0.2/dependencies
which depends on reqwest which depends on openssl | 18:36:15 |
| @curid:matrix.org | Redacted or Malformed Event | 18:36:31 |
| Willow | but even with openssl-sys gone, russimp-sys still is a c library that needs compilation | 18:38:34 |
| @curid:matrix.org | I don't think rustls-tls depend on openssl https://github.com/jkvargas/russimp-sys/blob/main/Cargo.toml#L56 | 18:40:07 |
| @curid:matrix.org | might save you some headache though | 18:40:19 |
| Willow | │ ├── russimp-sys v2.0.2
│ │ [build-dependencies]
│ │ ├── reqwest v0.11.27
│ │ │ ├── hyper-tls v0.5.0
│ │ │ │ ├── bytes v1.9.0
│ │ │ │ ├── hyper v0.14.32 (*)
│ │ │ │ ├── native-tls v0.2.12
│ │ │ │ │ ├── log v0.4.25
│ │ │ │ │ ├── openssl v0.10.68
│ │ │ │ │ │ ├── bitflags v2.8.0
│ │ │ │ │ │ ├── cfg-if v1.0.0
│ │ │ │ │ │ ├── foreign-types v0.3.2
│ │ │ │ │ │ │ └── foreign-types-shared v0.1.1
│ │ │ │ │ │ ├── libc v0.2.169
│ │ │ │ │ │ ├── once_cell v1.20.2
│ │ │ │ │ │ ├── openssl-macros v0.1.1 (proc-macro)
│ │ │ │ │ │ │ ├── proc-macro2 v1.0.93 (*)
│ │ │ │ │ │ │ ├── quote v1.0.38 (*)
│ │ │ │ │ │ │ └── syn v2.0.96 (*)
│ │ │ │ │ │ └── openssl-sys v0.9.104
│ │ │ │ │ │ └── libc v0.2.169
│ │ │ │ │ │ [build-dependencies]
│ │ │ │ │ │ ├── cc v1.2.10 (*)
│ │ │ │ │ │ ├── pkg-config v0.3.31
│ │ │ │ │ │ └── vcpkg v0.2.15
│ │ │ │ │ ├── openssl-probe v0.1.5
│ │ │ │ │ └── openssl-sys v0.9.104 (*)
| 18:43:05 |
| Willow | reqwest is totally overkill there, and i've already complained about their shitty build time stuff. i don't think this is the issue though. | 18:44:32 |
 rosssmyth | For the targets listed in lib/systems/examples.nix, what is generally considered "canon"? My guess is GCC since that's what the default stdenv uses. As far as I can tell there is no concept of a "Clang triple," only a "rustTarget," in terms of platform translations. But there are cases where Clang and GCC (and Zig (at least it used to, I'd have to check now days), Bazel, ...) diverge. Should more mappings be added to lib/systems? | 18:54:07 |
| 16 Apr 2025 |
|  @awwpotato:envs.net joined the room. | 01:48:36 |
 Tristan Ross | A clang triple is very similar to a GCC triple in a way that most of the time it should just work. | 02:16:09 |
| Tristan Ross | And it's likely the amount of possible clang triples are more than what GCC supports. | 02:16:40 |
| rosssmyth | Sure. But what about the times when it doesn't work | 02:16:56 |
| Tristan Ross | Also, the thing with the default stdenv is that is only true for Linux. | 02:16:59 |
| Tristan Ross | It's rare, rare enough you're more likely to get asserts within nix or nothing absolutely supports. | 02:17:26 |
| rosssmyth | Well one that has been found is that arm-none-eabi means two different things. | 02:18:00 |
| rosssmyth | I know there are others but don't know them off-hand | 02:18:24 |
| Tristan Ross | I have had thoughts of adding specific toolchain attributes into the systems aside from the actual toolchain tools (cc, libc, linker, etc.). This would focus on CPU model optimizations but could apply to the triple. | 02:18:40 |
| Tristan Ross | Yeah if you find a case where things just completely do not match then report it to the stdenv team. | 02:18:58 |
| rosssmyth | And then Zig, at least last I checked, the triples were different from GCC and Clang. | 02:19:11 |
