C - Revision history

Skaphi at 19:29, 24 February 2026

2026-02-24T19:29:34Z

← Older revision		Revision as of 19:29, 24 February 2026
Line 272:		Line 272:
	to find C/C++ header files. Nixpkgs adds wrapper to all language server [https://clangd.llvm.org/ clangd] (recommend), [https://github.com/MaskRay/ccls ccls] and [https://github.com/cquery-project/cquery cquery] to extend the include path of these tools. [https://github.com/MaskRay/ccls/wiki CCLS] also provides extensive documentation on how to setup a project/editors to make use of it.		to find C/C++ header files. Nixpkgs adds wrapper to all language server [https://clangd.llvm.org/ clangd] (recommend), [https://github.com/MaskRay/ccls ccls] and [https://github.com/cquery-project/cquery cquery] to extend the include path of these tools. [https://github.com/MaskRay/ccls/wiki CCLS] also provides extensive documentation on how to setup a project/editors to make use of it.

			But this is not enough for all projects. If you use clangd and your project generates a <code>compile_commands.json</code> which refers to a compiler which is in <code>/nix/store</code> you will need to set up your editor to start clangd with the following flags <code>clangd --query-driver=/nix/store//bin/g++ --query-driver=/nix/store//bin/gcc</code>. Clangd needs to query the compiler you are actually using to be able to find where the standard library headers are. This involves executing other binaries so clangd considers this unsecure for non-standard compiler paths. The flags whitelists all gcc and g++ compilers in the nix store.
	== Use a different compiler version ==		== Use a different compiler version ==

Mightyiam: Links to relevant Nixcademy blog posts

2025-11-28T12:39:07Z

Links to relevant Nixcademy blog posts

← Older revision		Revision as of 12:39, 28 November 2025
Line 416:		Line 416:

	[https://www.youtube.com/watch?v=zEsT4fw1pL0 Nix Friday about C/CPP infrastructure in Nix]		[https://www.youtube.com/watch?v=zEsT4fw1pL0 Nix Friday about C/CPP infrastructure in Nix]

			[https://nixcademy.com/posts/cpp-with-nix-in-2023-part-1-shell/ C++ with Nix in 2023, Part 1: Developer Shells]

			[https://nixcademy.com/posts/cpp-with-nix-in-2023-part-2-package/ C++ with Nix in 2023, Part 2: Package Generation and Cross-Compilation]

	[[Category:Languages]]		[[Category:Languages]]
	[[Category:Cookbook]]		[[Category:Cookbook]]

Phanirithvij: copied from old wiki

2025-03-16T07:10:02Z

copied from old wiki

← Older revision		Revision as of 07:10, 16 March 2025
Line 5:		Line 5:

	The way nixpkgs and its stdenv handles compiling and linking is very different from other Linux distributions.		The way nixpkgs and its stdenv handles compiling and linking is very different from other Linux distributions.
	In more conventional Linux distributions it's usual that header files are put into well known paths i.e. <code>/usr/include</code>, where the compiler will look for them. Same is true when linking against libraries, which are put in a few places, where the build-time linker will find them. Dynamically linked libraries will have a run-time linker (also known as <code>ld.so</code>) set as an interpreter.		In more conventional Linux distributions it's usual that header files are put into well known paths i.e. <code>/usr/include</code>, where the compiler will look for them.
			Same is true when linking against libraries, which are put in a few places, where the build-time linker will find them.
			Dynamically linked libraries will have a run-time linker (also known as <code>ld.so</code>) set as an interpreter.
	This linker reads <code>/etc/ld.so.conf</code> to figure out where to find libraries.		This linker reads <code>/etc/ld.so.conf</code> to figure out where to find libraries.
	In nixpkgs in contrast this information is provided by environment variables.		In nixpkgs in contrast this information is provided by environment variables.
Line 54:		Line 56:
	using the <code>-isystem</code> flag.		using the <code>-isystem</code> flag.

	However, while the <code>$out/include</code> folder will be included by default, it may sometimes not be enough when the lib puts the header in a subfolder (for instance, gtk2 and gtk3 uses subdirectories like <code>$out/include/gtk-2.0</code> instead to avoid conflict between versions). To deal with this kind of libraries, one can use `pkg-config`: the idea is simply to add `pkg-config` in the <code>nativeBuildInputs</code>, and then to start the <code>buildPhase</code> with:		However, while the <code>$out/include</code> folder will be included by default, it may sometimes not be enough when the lib puts the header in a subfolder (for instance, gtk2 and gtk3 uses subdirectories like <code>$out/include/gtk-2.0</code> instead to avoid conflict between versions). To deal with this kind of libraries, one can use <code>pkg-config</code>: the idea is simply to add <code>pkg-config</code> in the <code>nativeBuildInputs</code>, and then to start the <code>buildPhase</code> with:
	<syntaxHighlight lang=nix>		<syntaxHighlight lang=nix>
	buildPhase = ''		buildPhase = ''
Line 104:		Line 106:
	== Hardening flags ==		== Hardening flags ==
	To improve the security of applications the wrapper also injects additional hardening compile flags into the application. These nix flags enable different compiler flags, as seen in the [https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs manual].		To improve the security of applications the wrapper also injects additional hardening compile flags into the application. These nix flags enable different compiler flags, as seen in the [https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs manual].
	Under some circumstances this can make programs fail to build or function. For example, the `fortify` flag enables the `-O2` optimization level -- if you want to change this, you need to disable the `fortify` flag and re-add the compiler flags manually (`env.NIX_CFLAGS_COMPILE = [ "-O" "....."]`).		Under some circumstances this can make programs fail to build or function. For example, the <code>fortify</code> flag enables the <code>-O2</code> optimization level -- if you want to change this, you need to disable the <code>fortify</code> flag and re-add the compiler flags manually (<code>env.NIX_CFLAGS_COMPILE = [ "-O" "....."]</code>).
	To disable all hardening options one can export the environment variable <code>hardeningDisable="all"</code>.		To disable all hardening options one can export the environment variable <code>hardeningDisable="all"</code>.

	This also works for derivations like that:		This also works for derivations like that:

Phanirithvij: fix command

2025-03-13T05:53:57Z

fix command

← Older revision		Revision as of 05:53, 13 March 2025
Line 272:		Line 272:

	Adding a different c compiler to <code>buildInputs</code> in a nix expression will not change the default compiler		Adding a different c compiler to <code>buildInputs</code> in a nix expression will not change the default compiler
	available in <code>$PATH</code>. Instead, nixpkgs provides a several alternative <code>stdenv</code> which you can search with <code>nix search stdenv</code> so for example:		available in <code>$PATH</code>. Instead, nixpkgs provides a several alternative <code>stdenv</code> which you can search with <code>nix search nixpkgs stdenv</code> so for example:

	<syntaxHighlight lang=nix>		<syntaxHighlight lang=nix>

Widlarizer: Link to Debug Symbols page

2024-07-10T07:17:24Z

Link to Debug Symbols page

← Older revision		Revision as of 07:17, 10 July 2024
Line 238:		Line 238:

	== Debug symbols ==		== Debug symbols ==

			See also: [[Debug Symbols]]

	By default debug symbols are stripped of in the fixup phase of a package build.		By default debug symbols are stripped of in the fixup phase of a package build.

Mic92: imported from old wiki

2024-06-23T10:27:46Z

imported from old wiki

← Older revision		Revision as of 10:27, 23 June 2024
Line 103:		Line 103:

	== Hardening flags ==		== Hardening flags ==
	To improve the security of applications the wrapper also injects additional hardening compile flags into the application.		To improve the security of applications the wrapper also injects additional hardening compile flags into the application. These nix flags enable different compiler flags, as seen in the [https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs manual].
	Under some circumstances this can make programs fail to build or function.		Under some circumstances this can make programs fail to build or function. For example, the `fortify` flag enables the `-O2` optimization level -- if you want to change this, you need to disable the `fortify` flag and re-add the compiler flags manually (`env.NIX_CFLAGS_COMPILE = [ "-O" "....."]`).
	To disable all hardening options one can export the environment variable <code>hardeningDisable="all"</code>.		To disable all hardening options one can export the environment variable <code>hardeningDisable="all"</code>.
	This also works for derivations like that:		This also works for derivations like that:

Mic92: imported from old wiki

2024-05-13T08:56:13Z

imported from old wiki

← Older revision		Revision as of 08:56, 13 May 2024
Line 4:		Line 4:
	== Differences between nixpkgs and the rest ==		== Differences between nixpkgs and the rest ==

	The way nixpkgs and its stdenv handles compiling and linking is very different from other ~~linux~~ distributions.		The way nixpkgs and its stdenv handles compiling and linking is very different from other Linux distributions.
	~~Usually~~ header files are put into well known paths i.e. <code>/usr/include</code>, where the compiler will		In more conventional Linux distributions it's usual that header files are put into well known paths i.e. <code>/usr/include</code>, where the compiler will look for them. Same is true when linking against libraries, which are put in a few places, where the build-time linker will find them. Dynamically linked libraries will have a run-time linker (also known as <code>ld.so</code>) set as an interpreter.
	look for them. Same is true when linking against libraries, which are put in a few places, where the build-time
	linker will find them. Dynamically linked libraries will have a run-time linker (also known as <code>ld.so</code>) set as an interpreter.
	This linker reads <code>/etc/ld.so.conf</code> to figure out where to find libraries.		This linker reads <code>/etc/ld.so.conf</code> to figure out where to find libraries.
	In nixpkgs in contrast this information is provided by environment variables.		In nixpkgs in contrast this information is provided by environment variables.

imported>Phip1611: gcc_multi: add sectiion

2024-03-18T16:11:04Z

gcc_multi: add sectiion

@@ Line 203: / Line 203: @@
 [nix-shell:~] $ echo 'int main {}' > hello.c
 [nix-shell:~] $ cmake .
 </syntaxHighlight>

imported>Clerie at 10:39, 28 December 2023

2023-12-28T10:39:34Z

← Older revision		Revision as of 10:39, 28 December 2023
Line 117:		Line 117:
	</syntaxHighlight>		</syntaxHighlight>

	~~It is also possible to only enable certain parts:~~

			It is also possible to only disable certain parts, for example <code>-Werror=format-security</code>:

	<syntaxHighlight lang=nix>		<syntaxHighlight lang=nix>

imported>Mic92: /* Use a different compiler version */

2022-11-15T07:20:40Z

Use a different compiler version

← Older revision		Revision as of 07:20, 15 November 2022
Line 273:		Line 273:
	</syntaxHighlight>		</syntaxHighlight>

	- Available gcc based stdenv variants: gcc{49,6-12}Stdenv, gccMultiStdenv (32bit/64bit mixed support)		* Available gcc based stdenv variants: gcc{49,6-12}Stdenv, gccMultiStdenv (32bit/64bit mixed support)
	- Available clang based stdenv variants: llvmPackages_[5-13].{stdenv,libcxxStdenv}, clangMultiStdenv (32bit/64bit mixed support)		* Available clang based stdenv variants: llvmPackages_[5-13].{stdenv,libcxxStdenv}, clangMultiStdenv (32bit/64bit mixed support)

	Those stdenv instances can be also constructed using the <code>overrideCC</code> function:		Those stdenv instances can be also constructed using the <code>overrideCC</code> function: