When trying to do stuff in nixos out of standard with nix shell I often run into problems that some packages or libraries are there, it’s just that their paths are incorrect. In any linux distro but nixos (and guix probably) I would solve this by creating soft link with ln -s command or adding library or executable to the PATH so that linker, application or script could find it. Yet in nixos where is just no /usr/sbin/ or /lib or something like what, everything is placed in nix store with concrete hash for concrete build version. So even if for example I created soft link in /usr/sbin/ from /nix/store, that would only be good for that nix-shell build, and next time I start nix-shell I would need to create soft link again…
And this leads to my question:
What is general way to create soft links or aliases of some sort in .nix file, that it doesn’t matter if it is gcc, bash, perl or mosquitto, so that my provided path links to one which nix shell builds?
Have you considered putting that library in your shells buildInputs?
From what I have experienced so far, this works.
That did solve library problem thx. Hmm not if only where was a simple way to solve executables paths problems hmmm…
What do you mean?
As I said, adding to buildInputs usually does the job for me and libraries as well as executables.
Do you have a concrete example where it does not work?
One concrete example would be me having trouble with gcc. In my project cmake wants gcc-4.8, and g+±4.8. Yet I can only create nix-shell with gcc (not the gcc-4.8!) which is of version 4.8.
In a more abstract way if thing I am trying to build needs /bin/foo and buildInputs does its magic and creates /bin/foo its all good. Problems rise, when build looks for /usr/bin/foo for example, and buildInput creates /bin/foo so as a result build doesn’t find foo.
Does it require the executable with name gcc-4.8 (or something like that) or does it require a gcc that prints 4.8.x on gcc --version?
The gcc available as gcc in stdenv is latest. If you need an older GCC as gcc, then you need to change the stdenv.
As I’m on mobile I can’t lookup documentation on that, but on the nixos.wiki there was a page named “C”, “GCC”, “C++”, or something like that, explaining how to change the available GCC in stdenv.
It requires exectuable with name gcc-4.8 and g++-4.8.
I have already checked wiki page on with C and managed to get gcc --version 4.8, but what does not work for me.
For me this sounds like a weird requirement of cmake and I’d try to patch the CMakeList.txt such that it accepts explicitly named compilers as well as the one without version in the name, as long as version is correct.
Last but not least, as far as I remember, you can provide a variable to cmake which will make it use the given compilers, no matter what.
Also I’d perhaps ask why this limitation exist. Its rarely necessary to actually use an old version of a compiler, but instead accept any compiler since a certain version and limit its feature set through capability flags, that enable or disable certain addons or even force a certain level of ISO support.
Therefore I’d propose to propose upstream to loosen that constraint and accept that since 4.8s initial release 5 years have passed.
Its because application is compiled for centos 7 and it doesn’t support newer gcc.
But you do.
Centos 8 probably does.
GCC 9 is probably producing output that behaves the same, at least on your machine.
And even on centos 7, gcc will be of 4.8. So the version constraint is checked wrong. And even if there is a gcc-4.8 available in the path… It could even be clang… So what is this important with the name?
Whatever checks for the correct version, should do it proper than beeing fixed to a filename…
Upstream doing the wrong checks is not a problem of nix(OS).
Said that, it should be relatively easy using mkScript (IIRC, real name might be slightly different) to create a script named gcc-4.8 which just calls through to whatever gcc is available in stdenv.