C: Difference between revisions - Official NixOS Wiki

(2 intermediate revisions by one other user not shown)

Line 5:

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.

In nixpkgs in contrast this information is provided by environment variables.

Line 54:

Line 56:

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:

buildPhase = ''

Line 104:

Line 106:

== 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].

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>.

This also works for derivations like that:

Line 272:

Line 275:

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:

Line 413:

Line 416:

[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:Cookbook]]

@@ Line 5: / Line 5: @@
 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.
 In nixpkgs in contrast this information is provided by environment variables.
@@ Line 54: / Line 56: @@
 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>
 buildPhase = ''
@@ Line 104: / Line 106: @@
 == 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].
-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>.
 This also works for derivations like that:
@@ Line 272: / Line 275: @@
 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>
@@ Line 413: / Line 416: @@
 [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:Cookbook]]