C: Difference between revisions

(7 intermediate revisions by 6 users not shown)

Line 4:

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

look for them. Same is true when linking against libraries, which are put in a few places, where the build-time

Same is true when linking against libraries, which are put in a few places, where the build-time linker will find them.

linker will find them. Dynamically linked libraries will have a run-time linker (also known as <code>ld.so</code>) set as an interpreter.

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 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 105:

== 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 <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 117:

Line 118:

</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>:

Line 203:

Line 204:

[nix-shell:~] $ echo 'int main {}' > hello.c

[nix-shell:~] $ cmake .

</syntaxHighlight>

== gcc multilib ==

<code>pkgs.gcc_multi</code> exports a <code>gcc</code> in a multilib variant, which can produce 32-bit and 64-bit x86 code at the same time. However, <code>gcc_multi</code> falls back to the gcc version coming from <code>pkgs.gcc</code>. To use a specific version of gcc, you might use something like that:

{

gcc11_multi = pkgs.wrapCCMulti pkgs.gcc11;

// or

gcc13_multi = pkgs.wrapCCMulti pkgs.gcc13;

}

</syntaxHighlight>

Line 228:

Line 241:

== Debug symbols ==

@@ Line 4: / Line 4: @@
 == 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.
-look for them. Same is true when linking against libraries, which are put in a few places, where the build-time
+Same is true when linking against libraries, which are put in a few places, where the build-time linker will find them.
-linker will find them. Dynamically linked libraries will have a  run-time linker (also known as <code>ld.so</code>) set as an interpreter.
+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 56: / 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 105: / Line 105: @@
 == 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 <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 117: / Line 118: @@
 </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>
@@ Line 203: / Line 204: @@
 [nix-shell:~] $ echo 'int main {}' > hello.c
 [nix-shell:~] $ cmake .
+</syntaxHighlight>
+== gcc multilib ==
+<code>pkgs.gcc_multi</code> exports a <code>gcc</code> in a multilib variant, which can produce 32-bit and 64-bit x86 code at the same time. However, <code>gcc_multi</code> falls back to the gcc version coming from <code>pkgs.gcc</code>. To use a specific version of gcc, you might use something like that:
+<syntaxHighlight lang=nix>
+{
+  gcc11_multi = pkgs.wrapCCMulti pkgs.gcc11;
+  // or
+  gcc13_multi = pkgs.wrapCCMulti pkgs.gcc13;
+}
 </syntaxHighlight>
@@ Line 228: / Line 241: @@
 == Debug symbols ==
+See also: [[Debug Symbols]]
 By default debug symbols are stripped of in the fixup phase of a package build.
@@ Line 260: / 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 273: / Line 288: @@
 </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: