| 2 Dec 2024 |
 Artturin | overrideDrv is older and no longer used | 18:58:47 |
 szlend | we have too many ways of overriding | 18:58:58 |
| Artturin | * overrideDerivation is older and no longer used | 18:59:08 |
| Artturin | In reply to @artturin:matrix.org
overrideDerivation is older and no longer used Because we have overrideAttrs for a long time now | 18:59:48 |
| Artturin | I assume, I wasn't around back then | 19:00:26 |
| szlend | Couldn't makeOverridable fix up __spliced in the same way though? | 19:00:55 |
| Artturin | __spliced is added after makeOverridable/callPackage are called | 19:03:45 |
| Artturin | So would have to be done in splice.nix | 19:05:22 |
| Artturin | Like a possible overrideAttrs fix would do https://github.com/NixOS/nixpkgs/pull/201734 | 19:05:45 |
| 3 Dec 2024 |
|  getchoo changed their profile picture. | 06:06:29 |
|  xin left the room. | 08:32:26 |
| xin joined the room. | 08:32:46 |
 Alexandros Liarokapis | I currently work on embedded and maintain multiple libraries and projects for different cortex-m devices. | 08:56:54 |
| Alexandros Liarokapis | I found it very tiring to build gcc for each different fpu/mcu combination, so I currently have a faux-stdenv that uses the arm toolchain instead. | 08:57:51 |
| Alexandros Liarokapis | I have been trying for the past year get a few cmake & optimization changes upstream to make nix stdenv stdlib leaner for such projects, these are still mostly pending | 08:58:45 |
| Alexandros Liarokapis | this fixes some issues that I had with the nix cross-compilation infra since at least we get similar binary sizes | 08:59:07 |
| Alexandros Liarokapis | instead of using the upstream arm toolchain, it would be useful to use nix to build it but maintain a single toolchain for all different fpu/mcu targets | 08:59:52 |
| Alexandros Liarokapis | I think this mostly means building gcc with a huge multilib | 09:00:40 |
| Alexandros Liarokapis | * instead of using the upstream arm toolchain, it would be useful to use the native nix cross-compilation but maintain a single toolchain for all different fpu/mcu targets so that you don't rebuild gcc for each different combination. | 09:01:17 |
| Alexandros Liarokapis | * I have been trying for the past year to get a few cmake & optimization changes upstream to make nix stdenv stdlib leaner for such projects, these are still mostly pending | 09:01:43 |
| Alexandros Liarokapis | I also think I could somehow use the clang cross-compilation infra for this but I am not at all familiar with it | 09:02:21 |
| Alexandros Liarokapis | and thoughts ? | 09:02:23 |
| Alexandros Liarokapis | * any thoughts? | 09:02:34 |
 kuruczgy | I think clang supports emitting just LLVM IR (.bc files), and only emitting the actual host platform machine code after linking the final binary (this is how LTO works AFAIK). So if the libs could just be compiled to .bc, you would not have to recompile it to each different fpu/mcu combo. (Of course this only works if the libs don't make assumptions about the host, e.g. they don't require you to already specify the exact mcu at compile time.) | 11:47:52 |
 Randy Eckenrode | From what I understand, LLVM bitcode is not portable. It’s possible that may work, but it also may not work. This was a frequent source of speculation on Apple platforms before Apple Silicon was announced. If Apple were requiring bitcode submissions to the App Store, does that mean Apple could recompile everyone’s apps for ARM64? According to Chris Lattner, no. | 12:37:16 |
| Randy Eckenrode | However, the pain seems to be with having to build a toolchain for every combination. There are some changes in staging that should allow one LLVM toolchain to be used to target different platforms | 12:38:08 |
| Randy Eckenrode | * | 12:38:12 |
|  @rsdy:rustch.at changed their display name from rsdy to rsdy (old). | 18:05:48 |
| @rsdy:rustch.at left the room. | 18:56:54 |
| 4 Dec 2024 |
 alexfmpe | nix-build -A pkgsCross.aarch64-android.llvmPackages.compiler-rt fails with
/build/compiler-rt-src-18.1.8/compiler-rt/lib/builtins/os_version_check.c:287:10: fatal error: 'pthread.h' file not found
287 | #include <pthread.h>
| ^~~~~~~~~~~
1 error generated.
| 00:36:41 |
