Exotic Nix Targets | 332 Members | |
| 102 Servers |
| Sender | Message | Time |
|---|---|---|
| 3 Sep 2023 | ||
i'm going to see if patching out the -fno-integrated-as from the build system works, because the reason it's there in the first place is a four year old bug so maybe it's fixed now? | 23:49:44 | |
| 4 Sep 2023 | ||
In reply to @raitobezarius:matrix.orgdoes this translate to flakes in any way? or otherwise how would i do this inside nix rather than running a command. see https://artemis.sh/2023/06/06/cross-compile-nixos-for-great-good.html#humility for an example where i define a flake for a program that exports both a native build output and a cross-build output | 00:10:46 | |
| i then import that flake in another repo (see https://artemis.sh/assets/posts/2023-06-06-cross-compile-nixos-for-great-good/flake-with-humility.nix for how i do that) to include it in the systemPackages for a cross-built disk image | 00:11:30 | |
| * i then import that flake in another repo (see https://artemis.sh/assets/posts/2023-06-06-cross-compile-nixos-for-great-good/flake-with-humility.nix for how i do that) to include the cross-build variant in the systemPackages for a cross-built disk image | 00:11:48 | |
In reply to@kity:kity.wtfit doesn't | 00:28:47 | |
maybe i can add llvmPackagesBuildBuild.binutils-unwrapped for (unprefixed, as expected) as | 00:29:19 | |
In reply to@kity:kity.wtf | 00:44:21 | |
| dammit | 00:44:23 | |
| https://github.com/chimera-linux/cports/blob/master/contrib/firefox/patches/clang-ias.patch | 01:10:59 | |
| okay I need help. for context I'm on freebsd, not cross compiled just normal, but I am not sure if that matters here I tried building gcc: To the best of my knowledge, the cycle is as follows: gcc-lib/lib/*.so has rpaths for gcc-out/lib, and gcc-out/nix-support/propagated-build-inputs lists gcc-lib. I had my friend build the same setup on linux and the propagated-build-inputs link was still there but the rpath was not. The directory that the rpath points to does not contain any shared objects, so this is probably the link that needs to be broken. The thing that gets me is that I think the rpath is being set by nixpkgs/pkgs/stdenv/generic/setup.sh: there's an unconditional call to | 02:24:03 | |
| any advice appreciated | 02:24:07 | |
| I think gcc.lib is normally not expected to refer to gcc.out | 06:44:27 | |
| 06:45:21 | |
gcc uses pkgs/development/compilers/gcc/default.nix: NIX_NO_SELF_RPATH = true; to avoid self-rpaths. | 06:46:19 | |
| 14:42:30 | ||
| 14:44:46 | ||
| how is nixpkgs bootstrapped? | 18:49:31 | |
| i'm trying to explore the possibility of having a system whose "native" architecture is wasm64-wasi but always cross-compiles packages to the host architecture. that way, everything is cross compiled using a "standard" wasm64-wasi toolchain and you could, for example, have heterogenous machines that both specify wasm64-wasi in boot.binfmt.emulatedSystems and are then able to share packages | 19:06:24 | |
unfortunately if i try to do for instance, NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 nix-build . -A stdenv --argstr system "wasm64-wasi" it exits because ENOENT when calling /bin/bash. i don't know if bash in this case is actually nonexistent or if it's a different issue (like bad linker path) but i don't actually understand how nixpkgs bootstraps itself or how to generate a bootstrap tarball or anything like that. it may not even be feasible at this point to generate a wasm stdenv! but i'd like to try and document it. | 19:12:40 | |
| the nixpkgs bootstrap routine is in pkgs/stdenv | 19:21:21 | |
| you can in fact bootstrap without a bootstrap tarball if you're willing to temporarily copy some files off the host | 19:21:46 | |
| the way it works is that there's a bootstrap routine for each host platform and it incrementally builds more and more packages out of nothing until it can instantiate all-packages in some meaningful way, then you can do whatever you want from there to achieve self-sufficiency | 19:22:44 | |
| where is the bootstrap routine located? | 19:25:55 | |
| presumably there's one for x86_64-linux but not wasm64-wasi? | 19:26:12 | |
| for which host platform? | 19:26:12 | |
| there's one for linux in general, it's in pkgs/stdenv/linux | 19:26:26 | |
| I truthfully don't know a lot about how the particular stdenv gets selected, when I was messing with it I just blindly grepped through and added cases until it worked | 19:27:26 | |
| interesting | 19:30:58 | |
| so i suppose for this it would mean creating a bootstrap for wasi | 19:32:34 | |
| okay okay hang on I can think about this more critically - creating a stdenv for wasi would imply that you had already compiled nix itself for wasi and you wanted to boot nixpkgs under that environment | 19:33:29 | |