I’m trying to manage different versions of GCC and heard nix could help. I will start abstract then include some specifics at the bottom.
It seems as though the package management is doing its job, but for some reason I’m running into various GCC compilation issues for the project I’m managing with nix.
I’m trying to run a CUDA application - the first issue I ran into was it could not find cuda_runtime.h
when the gcc command gave an absolute path to the correct includes directory that had cuda_runtime.h
in it. I resolved this by using nix to manage its own cuda toolkit - for some reason GCC could now all of the sudden compile without this error.
Now I’m trying to compile the exact application (cloned via git), and gcc cannot find a basic header file for the project when given the correct gcc -I/path/to/include
path. I am either misunderstanding what the capabilities are, or something is wrong with my nix gcc installation?
Git repository I’m trying to run: GitHub - ggerganov/llama.cpp: LLM inference in C/C++
Build sequence I’ve run: cuda build instructions
Build sequence:
cmake -B build -DGGML_CUDA=ON # had header location errors with cuda until I installed via nix pkg
cmake --build build --config Release # has errors with gcc finding github project headers
My cuda-shell.nix file:
let
config = {
allowUnfree = true;
};
pkgs = import <nixpkgs> { inherit config; };
in
pkgs.mkShell.override { stdenv = pkgs.gcc12Stdenv; }
rec {
name = "cuda-env-shell";
buildInputs = with pkgs; [
# nix packages for older gcc version
gcc12 gcc12Stdenv
# nix packages for cuda toolkit
git gitRepo gnupg autoconf curl
procps gnumake util-linux m4 gperf unzip
cudatoolkit linuxPackages.nvidia_x11
libGLU libGL
xorg.libXi xorg.libXmu freeglut
xorg.libXext xorg.libX11 xorg.libXv xorg.libXrandr zlib
ncurses5 stdenv.cc binutils
];
shellHook = ''
export CUDA_PATH=${pkgs.cudatoolkit}
export EXTRA_LDFLAGS="-L/lib -L${pkgs.linuxPackages.nvidia_x11}/lib"
export EXTRA_CCFLAGS="-I/usr/include"
}
I received a similar template based on: CUDA - NixOS Wiki , simply added some tweaks for using an older version of GCC than my base system.
ETA: so I’ve run the gcc command that gives me an error, and I replaced the absolute/realpath of the -I/path/to/lib/include
with -I../relative/path/to/lib/include
and that seems to compile with my nix shell’s gcc. Is there an issue with nix accessing realpaths?
ETA: The issue has been diagnosed thanks to some help.
Due to the gcc wrapper condition for calling badPath and the way bad path handles any absolute path the project’s cmake build process fails because it converts header include paths to absolute filesystem paths. If I overwrite my NIX_ENFORCE_PURITY
to 0
, then this check never fails and I can continue with the build process. badPath might want to consider checking if the absolute path resolves to a relative path/subdirectory of the nix configuration file?