Cross Compiling - Revision history

Mightyiam: Link to Nixcademy post Cross-Compiling NixOS images

2025-12-27T03:02:15Z

Link to Nixcademy post Cross-Compiling NixOS images

← Older revision		Revision as of 03:02, 27 December 2025
Line 196:		Line 196:
	* [https://nixcademy.com/posts/cpp-with-nix-in-2023-part-2-package/ C++ with Nix in 2023, Part 2: Package Generation and Cross-Compilation, Nixcademy]		* [https://nixcademy.com/posts/cpp-with-nix-in-2023-part-2-package/ C++ with Nix in 2023, Part 2: Package Generation and Cross-Compilation, Nixcademy]
	* [https://nixcademy.com/posts/cross-compilation-with-nix/ Separation of Concerns in Cross-Compilation, Nixcademy]		* [https://nixcademy.com/posts/cross-compilation-with-nix/ Separation of Concerns in Cross-Compilation, Nixcademy]
			* [https://nixcademy.com/posts/cross-compile-nixos-images/ Cross-Compiling NixOS images, Nixcademy]

	[[Category:nix]]		[[Category:nix]]
	[[Category:Development]]		[[Category:Development]]

Mightyiam: Link to two relevant Nixcademy articles

2025-11-30T09:50:29Z

Link to two relevant Nixcademy articles

← Older revision		Revision as of 09:50, 30 November 2025
Line 194:		Line 194:

	* [https://logs.nix.samueldr.com/nixos/2018-08-03#1533327247-1533327971; 2018-08-03 discussion on #nixos] ([https://matrix.to/#/!AinLFXQRxTuqNpXyXk:matrix.org/$15333274371713496LOAor:matrix.org Mirror of chat on Matrix.org])		* [https://logs.nix.samueldr.com/nixos/2018-08-03#1533327247-1533327971; 2018-08-03 discussion on #nixos] ([https://matrix.to/#/!AinLFXQRxTuqNpXyXk:matrix.org/$15333274371713496LOAor:matrix.org Mirror of chat on Matrix.org])
			* [https://nixcademy.com/posts/cpp-with-nix-in-2023-part-2-package/ C++ with Nix in 2023, Part 2: Package Generation and Cross-Compilation, Nixcademy]
			* [https://nixcademy.com/posts/cross-compilation-with-nix/ Separation of Concerns in Cross-Compilation, Nixcademy]

	[[Category:nix]]		[[Category:nix]]
	[[Category:Development]]		[[Category:Development]]

Phanirithvij: add another way via nix-build cli to cross compile

2025-03-13T06:01:30Z

add another way via nix-build cli to cross compile

← Older revision		Revision as of 06:01, 13 March 2025
Line 20:		Line 20:
	</syntaxhighlight>You can perform the same operations using the CLI, and Nix will correctly evaluate the <code>localSystem</code> based on your current system:<syntaxhighlight lang="bash">		</syntaxhighlight>You can perform the same operations using the CLI, and Nix will correctly evaluate the <code>localSystem</code> based on your current system:<syntaxhighlight lang="bash">
	nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello # nix-legacy		nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello # nix-legacy
			nix-build '<nixpkgs>' --arg crossSystem '(import <nixpkgs> {}).lib.systems.examples.aarch64-multiplatform' -A hello # alternative way
	nix build nixpkgs#pkgsCross.aarch64-multiplatform.hello # nix3		nix build nixpkgs#pkgsCross.aarch64-multiplatform.hello # nix3
	</syntaxhighlight>All of the above snippets will resolve to the exact same derivation result, which will provide a binary for GNU Hello that can execute only on an <code>aarch64</code> system. There are many other systems <code>pkgsCross</code> has defined, you can see an exhaustive list of all of them on your system:<syntaxhighlight lang="bash">		</syntaxhighlight>All of the above snippets will resolve to the exact same derivation result, which will provide a binary for GNU Hello that can execute only on an <code>aarch64</code> system. There are many other systems <code>pkgsCross</code> has defined, you can see an exhaustive list of all of them on your system:<syntaxhighlight lang="bash">

FliegendeWurst: /* Tips and tricks */ NixOS config example

2025-01-10T08:36:52Z

Tips and tricks: NixOS config example

@@ Line 159: / Line 159: @@
+   }
 ) { }
 </syntaxhighlight>

Artturin: Improve examples

2024-10-29T21:14:40Z

Improve examples

← Older revision		Revision as of 21:14, 29 October 2024
Line 44:		Line 44:
	localSystem = "x86_64-linux";		localSystem = "x86_64-linux";
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";

	},		},
	}:		}:
	pkgs.mkShell {		pkgs.callPackage (
	# By default this provides gcc, ar, ld, and some other bare minimum tools		{
	}		mkShell,
			}:
			mkShell {
			# By default this provides gcc, ar, ld, and some other bare minimum tools
			}
			) { }
	</syntaxhighlight>Entering this development shell via <code>nix-shell shell.nix</code> will add the relevant compiler tools to your PATH temporarily. Similar to other Linux systems, all cross-compiling tools are prefixed with relevant platform prefixes, which means simply typing <code>gcc</code> will not work. However, the provided <code>mkShell</code> will introduce environment variables for your devshell, such as <code>$CC</code>, <code>$AR</code>, <code>$LD</code>, and more. At the time of writing, official documentation on an exhaustive list of these variables does not exist, but you can view them for your devshell through the command-line:<syntaxhighlight lang="bash">		</syntaxhighlight>Entering this development shell via <code>nix-shell shell.nix</code> will add the relevant compiler tools to your PATH temporarily. Similar to other Linux systems, all cross-compiling tools are prefixed with relevant platform prefixes, which means simply typing <code>gcc</code> will not work. However, the provided <code>mkShell</code> will introduce environment variables for your devshell, such as <code>$CC</code>, <code>$AR</code>, <code>$LD</code>, and more. At the time of writing, official documentation on an exhaustive list of these variables does not exist, but you can view them for your devshell through the command-line:<syntaxhighlight lang="bash">
	$ $EDITOR $(nix-build ./shell.nix) # opens your EDITOR with a massive bash script full of declare -x ...		$ $EDITOR $(nix-build ./shell.nix) # opens your EDITOR with a massive bash script full of declare -x ...
Line 61:		Line 67:

	If you would prefer to continue building within the devshell, you can use [https://nixos.org/guides/nix-pills/13-callpackage-design-pattern callPackage], which will ''magically'' resolve the dependencies for the correct architecture, provided you place them in the correct attributes:<syntaxhighlight lang="nix">		If you would prefer to continue building within the devshell, you can use [https://nixos.org/guides/nix-pills/13-callpackage-design-pattern callPackage], which will ''magically'' resolve the dependencies for the correct architecture, provided you place them in the correct attributes:<syntaxhighlight lang="nix">
	~~# shell.nix~~
	{		{
	pkgs ? import <nixpkgs> {		pkgs ? import <nixpkgs> {
	#localSystem = ~~...~~;		localSystem = "x86_64-linux";
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";
	},		},
Line 71:		Line 76:
	{		{
	mkShell,		mkShell,
			hello,
	pkg-config,		pkg-config,
	libGL,		libGL,
	}:		}:
	mkShell {		mkShell {
	# ~~Derivations that must run on the buildPlatform.~~		strictDeps = true;
			# host/target agnostic programs
			depsBuildBuild = [
			hello
			];
			# compilers & linkers & dependecy finding programs
	nativeBuildInputs = [		nativeBuildInputs = [
	pkg-config		pkg-config
	];		];
			# libraries
	# ~~Derivations that must link with the targetPlatform.~~
	buildInputs = [		buildInputs = [
	libGL		libGL
	];		];
	}		}
	) {}		) { }
	</syntaxhighlight>The above snippet will drop you into a devshell that provides <code>pkg-config</code> as a native binary (accessible through <code>$PKG_CONFIG</code>), while also allowing linking to a valid <code>libGL</code> for the <code>crossSystem</code>.		</syntaxhighlight>The above snippet will drop you into a devshell that provides <code>pkg-config</code> as a native binary (accessible through <code>$PKG_CONFIG</code>), while also allowing linking to a valid <code>libGL</code> for the <code>crossSystem</code>.

Line 109:		Line 118:

	=== Leveraging the binary cache ===		=== Leveraging the binary cache ===
	You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. Fortunately, there are a small set of systems that are actively built and cached officially. At the time of writing, this only includes <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. If your platform targets include these, you may be able to leverage a slight hack to avoid large-scale builds.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">		You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. Fortunately, there are a small set of systems that are actively built and cached officially. At the time of writing, this only includes <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. If your platform targets include these, you may be able to leverage a slight hack to avoid large-scale builds.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time, and the storage requirements will be higher due to duplicate(but different system) packages.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">
	let		let
	# this will use aarch64 binaries from binary cache, so no need to build those		# this will use aarch64 binaries from binary cache, so no need to build those
	pkgsArm = import <nixpkgs> {		pkgsArm = import <nixpkgs> {
	~~system~~ = "aarch64-linux";		localSystem = "aarch64-linux";
	};		};

Line 122:		Line 131:
	# we want to hack on SDL, don't want to hack on those. Some even don't cross-compile		# we want to hack on SDL, don't want to hack on those. Some even don't cross-compile
	inherit (pkgsArm)		inherit (pkgsArm)
	xorg libpulseaudio libGL guile systemd libxkbcommon		xorg
			libpulseaudio
			libGL
			guile
			systemd
			libxkbcommon
	;		;
	})		})
	];		];
	#localSystem = ~~...~~;		localSystem = "x86_64-linux";
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";
	};		};
	in pkgsCross.~~SDL2.override~~ {		in
	~~# These should be neither pkgsCross~~, ~~nor pkgsArm~~		pkgsCross.callPackage (
	~~# because those trigger~~		{
	~~# > cannot execute binary file: Exec format error~~		SDL2,
	~~# In this case it was enough to just use buildPackages variants~~,		wayland,
	~~# but in general, there may be problems~~		wayland-protocols,
	~~inherit (pkgsCross~~.~~buildPackages)~~		wayland-scanner,
	wayland wayland-protocols		}:
	;		SDL2.override {
	}		inherit
			wayland
			wayland-protocols
			wayland-scanner
			;
			}
			) { }
	</syntaxhighlight>		</syntaxhighlight>

Frontear: more clear edits with correct references to platforms

2024-10-13T19:13:44Z

more clear edits with correct references to platforms

← Older revision		Revision as of 19:13, 13 October 2024
Line 28:		Line 28:
	lib = import <nixpkgs/lib>;		lib = import <nixpkgs/lib>;
	pkgs = import <nixpkgs> {		pkgs = import <nixpkgs> {
			#localSystem = ...;
	crossSystem = lib.systems.examples.aarch64-multiplatform;		crossSystem = lib.systems.examples.aarch64-multiplatform;
	};		};
Line 63:		Line 64:
	{		{
	pkgs ? import <nixpkgs> {		pkgs ? import <nixpkgs> {
			#localSystem = ...;
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";
	},		},
Line 74:		Line 76:
	}:		}:
	mkShell {		mkShell {
	# Derivations that must run on ~~the localSystem, referred to as~~ the buildPlatform.		# Derivations that must run on the buildPlatform.
	nativeBuildInputs = [		nativeBuildInputs = [
	pkg-config		pkg-config
	];		];

	# Derivations that must link with ~~the crossSystem, referred to as~~ the targetPlatform.		# Derivations that must link with the targetPlatform.
	buildInputs = [		buildInputs = [
	libGL		libGL
Line 94:		Line 96:
	By using [[QEMU]], we can natively execute a cross-compiled binary through an emulation layer. This will result in degraded performance but is very suitable for testing the functionality of a binary.		By using [[QEMU]], we can natively execute a cross-compiled binary through an emulation layer. This will result in degraded performance but is very suitable for testing the functionality of a binary.

	If you are on NixOS, this functionality can be provided automatically on any cross-compiled binary by setting [https://nixos.org/manual/nixos/unstable/options#opt-boot.binfmt.emulatedSystems boot.binfmt.emulatedSystems] in your configuration. After rebuilding, attempting to run a cross-compiled binary will automatically invoke <code>qemu</code> indirectly.<syntaxhighlight lang="bash">		If you are on NixOS, this functionality can be provided automatically on any cross-compiled binary by setting [https://nixos.org/manual/nixos/unstable/options#opt-boot.binfmt.emulatedSystems boot.binfmt.emulatedSystems] in your configuration. After rebuilding, attempting to run a cross-compiled binary will automatically invoke <code>qemu</code> indirectly through the [https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html binfmt_misc kernel feature].<syntaxhighlight lang="bash">
	$ ./result		$ ./result
	Hello World!		Hello World!
Line 107:		Line 109:

	=== Leveraging the binary cache ===		=== Leveraging the binary cache ===
	You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. ~~However~~, ~~for some~~ systems~~, natively compiled binaries~~ are cached. At the time of writing, this only includes <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. ~~As a result~~, ~~this section is only applicable~~ to a ~~very small number of cross~~-~~compilation situations.~~		You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. Fortunately, there are a small set of systems that are actively built and cached officially. At the time of writing, this only includes <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. If your platform targets include these, you may be able to leverage a slight hack to avoid large-scale builds.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">

	~~You can leverage the binary cache to correctly substitute some applicable derivations without causing a local build~~.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">
	let		let
	# this will use aarch64 binaries from binary cache, so no need to build those		# this will use aarch64 binaries from binary cache, so no need to build those
Line 126:		Line 126:
	})		})
	];		];
			#localSystem = ...;
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";
	};		};
Line 151:		Line 152:

	* [https://logs.nix.samueldr.com/nixos/2018-08-03#1533327247-1533327971; 2018-08-03 discussion on #nixos] ([https://matrix.to/#/!AinLFXQRxTuqNpXyXk:matrix.org/$15333274371713496LOAor:matrix.org Mirror of chat on Matrix.org])		* [https://logs.nix.samueldr.com/nixos/2018-08-03#1533327247-1533327971; 2018-08-03 discussion on #nixos] ([https://matrix.to/#/!AinLFXQRxTuqNpXyXk:matrix.org/$15333274371713496LOAor:matrix.org Mirror of chat on Matrix.org])
	* [https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html Kernel documentation on binfmt_misc]

	[[Category:nix]]		[[Category:nix]]
	[[Category:Development]]		[[Category:Development]]

Frontear: minor grammar edit

2024-10-13T19:09:20Z

minor grammar edit

← Older revision		Revision as of 19:09, 13 October 2024
Line 2:		Line 2:
	[[Nixpkgs]] provides excellent support in configuring it for cross-platform compiling tasks since 18.09<sup>[citation needed]</sup>.		[[Nixpkgs]] provides excellent support in configuring it for cross-platform compiling tasks since 18.09<sup>[citation needed]</sup>.

	In order to prepare Nixpkgs for a cross-compiling environment, it needs to be aware of both the platform that performs the build-step, and the platform that will execute the resulting binaries. The former is referred to as the <code>buildPlatform</code>, while the latter is <code>hostPlatform</code>.<blockquote>If you were compiling a program from your system for a Raspberry PI, you would be the <code>buildPlatform</code> whereas the Raspberry PI would be the <code>hostPlatform</code>.</blockquote>Furthermore, in order to provide a more granular control to declaring dependencies in these environments, Nixpkgs derivations expose an exhaustive set of attributes that can explicitly define when are where dependencies are required. ~~An exhaustive~~ reference to these can be found in the [https://nixos.org/manual/nixpkgs/unstable/#ssec-stdenv-dependencies-propagated Nixpkgs manual].		In order to prepare Nixpkgs for a cross-compiling environment, it needs to be aware of both the platform that performs the build-step, and the platform that will execute the resulting binaries. The former is referred to as the <code>buildPlatform</code>, while the latter is <code>hostPlatform</code>.<blockquote>If you were compiling a program from your system for a Raspberry PI, you would be the <code>buildPlatform</code> whereas the Raspberry PI would be the <code>hostPlatform</code>.</blockquote>Furthermore, in order to provide more granular control to declaring dependencies in these environments, Nixpkgs derivations expose an exhaustive set of attributes that can explicitly define when are where dependencies are required. A full reference to these can be found in the [https://nixos.org/manual/nixpkgs/unstable/#ssec-stdenv-dependencies-propagated Nixpkgs manual].

	== Getting Started ==		== Getting Started ==

Frontear: add a small desc of host/build platform

2024-10-13T07:18:04Z

add a small desc of host/build platform

← Older revision		Revision as of 07:18, 13 October 2024
Line 1:		Line 1:
	{{Expansion}}		{{Expansion}}
	~~Cross compiling is well supported in~~ [[Nixpkgs]] since 18.09<sup>[citation needed]</sup>.		[[Nixpkgs]] provides excellent support in configuring it for cross-platform compiling tasks since 18.09<sup>[citation needed]</sup>.

			In order to prepare Nixpkgs for a cross-compiling environment, it needs to be aware of both the platform that performs the build-step, and the platform that will execute the resulting binaries. The former is referred to as the <code>buildPlatform</code>, while the latter is <code>hostPlatform</code>.<blockquote>If you were compiling a program from your system for a Raspberry PI, you would be the <code>buildPlatform</code> whereas the Raspberry PI would be the <code>hostPlatform</code>.</blockquote>Furthermore, in order to provide a more granular control to declaring dependencies in these environments, Nixpkgs derivations expose an exhaustive set of attributes that can explicitly define when are where dependencies are required. An exhaustive reference to these can be found in the [https://nixos.org/manual/nixpkgs/unstable/#ssec-stdenv-dependencies-propagated Nixpkgs manual].

	== Getting Started ==		== Getting Started ==
	~~There are~~ two ~~main entry points~~ to ~~configure~~ a ~~Nixpkgs instance for cross compilation. The simplest one is to leverage <code>pkgs.pkgsCross</code>~~:<syntaxhighlight lang="nix">		Nixpkgs exposes two configuration attributes that map internally to the expected behaviors of the build/host platforms as described above. These attributes can be set when importing Nixpkgs as a Nix expression:<syntaxhighlight lang="nix">
	let		let
	pkgs = import <nixpkgs> {};		pkgs = import <nixpkgs> {
	in pkgs~~.pkgsCross.aarch64-multiplatform~~.hello		localSystem = "x86_64-linux"; # buildPlatform
	</syntaxhighlight>The above will provide a derivation result for the hello derivation that can run on an <code>aarch64</code> system. ~~A slightly less simple~~, ~~but "purer" (i~~.~~e. reproducible)~~ snippet ~~involves configuring Nixpkgs as you import it~~:<syntaxhighlight lang="nix">		crossSystem = "aarch64-linux"; # hostPlatform
			};
			in pkgs.hello
			</syntaxhighlight>The above will provide a derivation result for the hello derivation that can run on an <code>aarch64-linux</code> system. This can sometimes be tedious especially for common <code>hostPlatform</code> targets. Fortunately, Nixpkgs exposes a <code>pkgsCross</code> attribute that provides pre-configured cross compiling targets. The snippet above converted to using <code>pkgsCross</code> can be shorted to:<syntaxhighlight lang="nix">
	let		let
	pkgs = import <nixpkgs> {		pkgs = import <nixpkgs> {
	~~# localSystem will always default to your current system, meaning it is not essential to define here.~~		localSystem = "x86_64-linux";
	~~# It is however, encouraged if you are trying to follow nix's purity model.~~

	localSystem = "x86_64-linux"; ~~# This should match the system you are compiling from (your running system)~~
	~~crossSystem = "aarch64-linux"; # This should match the system you are compiling for (your target system)~~
	};		};
	in pkgs.~~hello # The hello derivation will be built for~~ aarch64-~~linux~~		in pkgs.pkgsCross.aarch64-multiplatform.hello
	</syntaxhighlight>You can perform the same operations using the CLI, ~~though you~~ will ~~probably prefer to use~~ <code>~~pkgsCross~~</code> ~~in that case, as its less verbose~~:<syntaxhighlight lang="bash">		</syntaxhighlight>You can perform the same operations using the CLI, and Nix will correctly evaluate the <code>localSystem</code> based on your current system:<syntaxhighlight lang="bash">
	nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello # nix-legacy		nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello # nix-legacy
	nix build nixpkgs#pkgsCross.aarch64-multiplatform.hello # nix3		nix build nixpkgs#pkgsCross.aarch64-multiplatform.hello # nix3
Line 23:		Line 24:
	$ nix-instantiate --eval --expr 'builtins.attrNames (import <nixpkgs> {}).pkgsCross' --json \| nix-shell -p jq --command 'jq' # nix-legacy		$ nix-instantiate --eval --expr 'builtins.attrNames (import <nixpkgs> {}).pkgsCross' --json \| nix-shell -p jq --command 'jq' # nix-legacy
	$ nix eval --impure --expr 'builtins.attrNames (import <nixpkgs> {}).pkgsCross' --json \| nix run nixpkgs#jq # nix3		$ nix eval --impure --expr 'builtins.attrNames (import <nixpkgs> {}).pkgsCross' --json \| nix run nixpkgs#jq # nix3
	</syntaxhighlight>If you instead prefer to write your systems directly, through <code>localSystem</code> and <code>crossSystem</code>, you can refer to [https://github.com/NixOS/nixpkgs/blob/master/lib/systems/examples.nix nixpkgs/lib/systems/examples.nix] for ~~a list~~ of platforms exposed as attributes ~~(though it will be easier to use <code>pkgsCross</code> in this case)~~. These can be directly used in-place for the aforementioned arguments:<syntaxhighlight lang="nix">		</syntaxhighlight>If you instead prefer to write your systems directly, through <code>localSystem</code> and <code>crossSystem</code>, you can refer to [https://github.com/NixOS/nixpkgs/blob/master/lib/systems/examples.nix nixpkgs/lib/systems/examples.nix] for examples of platforms exposed as attributes. These can be directly used in-place for the aforementioned arguments:<syntaxhighlight lang="nix">
	let		let
	lib = import <nixpkgs/lib>;		lib = import <nixpkgs/lib>;
Line 40:		Line 41:
	{		{
	pkgs ? import <nixpkgs> {		pkgs ? import <nixpkgs> {
	# localSystem = "x86_64-linux"; ~~# not necessary but encouraged~~		localSystem = "x86_64-linux";
	crossSystem = "aarch64-linux";		crossSystem = "aarch64-linux";
	},		},
Line 86:		Line 87:
	</syntaxhighlight>The above snippet will drop you into a devshell that provides <code>pkg-config</code> as a native binary (accessible through <code>$PKG_CONFIG</code>), while also allowing linking to a valid <code>libGL</code> for the <code>crossSystem</code>.		</syntaxhighlight>The above snippet will drop you into a devshell that provides <code>pkg-config</code> as a native binary (accessible through <code>$PKG_CONFIG</code>), while also allowing linking to a valid <code>libGL</code> for the <code>crossSystem</code>.

	For more information regarding the above, namely the usage of <code>nativeBuildInputs</code> and <code>buildInputs</code>, see [https://nixos.org/manual/nixpkgs/stable/#ssec-stdenv-dependencies stdenv dependencies] for a in-depth explanation. Alternatively, a simplified explanation can be found in a comment on the [https://github.com/NixOS/nixpkgs/pull/50881 ~~nixpkgs~~ repo].		For more information regarding the above, namely the usage of <code>nativeBuildInputs</code> and <code>buildInputs</code>, see [https://nixos.org/manual/nixpkgs/stable/#ssec-stdenv-dependencies stdenv dependencies] for a in-depth explanation. Alternatively, a simplified explanation can be found in a comment on the [https://github.com/NixOS/nixpkgs/pull/50881 Nixpkgs repo].

	== Tips and tricks ==		== Tips and tricks ==

Frontear: improved wording in binary cache section

2024-10-10T22:13:29Z

improved wording in binary cache section

← Older revision		Revision as of 22:13, 10 October 2024
Line 106:		Line 106:

	=== Leveraging the binary cache ===		=== Leveraging the binary cache ===
	You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. However, for some systems, natively compiled binaries are ~~provided~~. At the time of writing, it only ~~supports~~ <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. As a result, this section is only applicable to a very small number of cross-compilation situations.		You will likely have noticed that resolving derivations through either pkgsCross or a configured Nixpkgs instance results in your system needing to build the binary. This is because cross-compiled binaries are not cached on the official [[Binary Cache\|binary cache]]. However, for some systems, natively compiled binaries are cached. At the time of writing, this only includes <code>aarch64-linux</code>, <code>aarch64-darwin</code>, <code>i686-linux</code>, <code>x86_64-linux</code>, and <code>x86_64-darwin</code>. As a result, this section is only applicable to a very small number of cross-compilation situations.

	You can leverage the binary cache to correctly substitute some applicable derivations without causing a local build.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">		You can leverage the binary cache to correctly substitute some applicable derivations without causing a local build.<blockquote>Please note that this is not recommended, as it hacks around some internal details of Nixpkgs which are subject to change at any time.</blockquote>An example of this using <code>pkgs.SDL2</code>:<syntaxhighlight lang="nix">

Frontear: add section for basics.

2024-10-10T22:12:31Z

add section for basics.

← Older revision		Revision as of 22:12, 10 October 2024
Line 33:		Line 33:

	== Development ==		== Development ==

			=== Basics ===

	Using the same ideas as above, we can create development environments which provide us with a compilation suite that can perform cross-compilation for us. A very simple [[Development environment with nix-shell\|development shell]] (colloquially called a "devshell") can be written as:<syntaxhighlight lang="nix">		Using the same ideas as above, we can create development environments which provide us with a compilation suite that can perform cross-compilation for us. A very simple [[Development environment with nix-shell\|development shell]] (colloquially called a "devshell") can be written as:<syntaxhighlight lang="nix">
	# shell.nix		# shell.nix