As far as i know there are three ways for compiler to locate libraries and headers. It can search in system lib and include folders for headers and libraries, i can provide their location when compiling with an argument, or i can specify it in environment variable. System folders don’t even exist in nixos, environment variables are empty. I suppose wraper script sets up enviroment for gcc to search for libreries and headers. And i suppose it finds them with help of nix builder when package is build, right? My point is that there seems to be no runtime system way to find libraries and headers. How do i install libraries system wide. I can install them to arbitrary folder and add it to environment variable, but is there a better way? And i also have a vscode with microsoft extensions and they seem to have no problems locating system c libraries. I wonder how they do it. I suppose they use some sort of vscode own library, and this library gets system libraries from vscode’s wraper script right? System c libraries are an important part of a system. I wonder how exactly does nixos provide them since it does not support FHS.
Yep. This is to prevent environment pollution. There are no random global libraries which will impart effectively random behavior on software you compile, NixOS guarantees that you know exactly what ends up in your binaries, and that you can compile what you want even if your system relies on different versions of certain dependencies. Replicating your build env is much easier if you don’t have random global cruft, too.
Ideally you don’t. NixOS offers alternatives that allow you to scope your libraries to specific projects - you should not need global libraries (except perhaps graphics libraries and kernel headers, which are handled specially, and should already be available), in fact the basic idea behind nix is that you don’t want them.
The “how” depends a bit on exactly what you want to do though. The basic trick is to use nix-shell, which will create an environment with variables set up to point to the dev headers you need. There are also other escape hatches for more specialized needs.
How you work this into your development flow depends on what you use and need, though, mind giving more details of what exactly you want to accomplish? In a way this is an A/B problem.
Depends on the extensions and how you installed vscode (and their extensions). A flatpak would run vscode in a cgroup that has its own file tree which does conform to FHS, for example. The nixpkgs-packaged extensions might use a NixOS-native mechanism similar to flatpaks, or patch the underlying scripts to have env variables set up correctly. Either way, those dependencies would be scoped to only exist in that context and not pollute your other build environments.
Each program on your system has its own full closure which is built to have its library locations hard-coded to specific paths in /nix/store (those paths will often be shared with other programs, but they arrive at the locations independently, instead of relying on a global prefix like traditional FHS distros). The nix pills cover the reasoning and implementation in way more detail than I can here: Preface - Nix Pills
Eelco’s original paper is also worth a read if you want to understand.