Installing software in your home directory: Difference between revisions

Jump to navigation Jump to search
no edit summary
(Marked this version for translation)
No edit summary
Line 82: Line 82:


<!--T:11-->
<!--T:11-->
The core of this software stack is provided by the <code>nixpkgs/16.09</code> module, which is loaded by default. This stack, internally managed using the Nix package manager, is located at <code>/cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09</code>. The environment variable <code>$EBROOTNIXPKGS</code> should be used to refer to this path.
The core of this software stack is provided by the <code>gentoo//2020</code> module, which is loaded by default. This stack, internally managed using the Gentoo package manager, is located at <code>/cvmfs/soft.computecanada.ca/gentoo/2020/usr</code>. The environment variable <code>$EBROOTGENTOO</code> should be used to refer to this path.
Under this location you can find all of the common packages typically included with Linux distributions, for instance <code>make</code>, <code>ls</code>, <code>cat</code>, <code>grep</code>, and so on. Typically, when you compile some software, the compiler and linker will automatically look for header files and libraries in the right location (via the environment variables <code>$CPATH</code> and <code>$LIBRARY_PATH</code>, respectively).
Under this location you can find all of the common packages typically included with Linux distributions, for instance <code>make</code>, <code>ls</code>, <code>cat</code>, <code>grep</code>, and so on. Typically, when you compile some software, the compiler and linker will automatically look for header files and libraries in the right location (via the environment variables <code>$CPATH</code> and <code>$LIBRARY_PATH</code>, respectively).
Some software, however, has been hard-coded to look under <code>/usr</code>. If that is the case, the compilation will typically fail, and needs to be explicitly told about <code>$EBROOTNIXPKGS</code>. Sometimes that means adjusting a Makefile, sometimes it needs to be specified in a certain <code>--with-</code> flag for the configure script, or a configuration file needs to be edited. If you are not sure how to do this please do not hesitate to ask for help.
Some software, however, has been hard-coded to look under <code>/usr</code>. If that is the case, the compilation will typically fail, and needs to be explicitly told about <code>$EBROOTGENTOO</code>. Sometimes that means adjusting a Makefile, sometimes it needs to be specified in a certain <code>--with-</code> flag for the configure script, or a configuration file needs to be edited. If you are not sure how to do this please do not hesitate to ask for help.


<!--T:12-->
<!--T:12-->
Similarly, if a package depends on a library that is provided by a module other than <code>nixpkgs</code>, you may need to provide the location of the header files and libraries of that module. Those other modules also provide an environment variable that starts with EBROOT and ends with the capitalized module name. For example, after you issue the command <code>module load hdf5</code>, you can find its installation in <code>$EBROOTHDF5</code>, its header files in <code>$EBROOTHDF5/include</code>, its library files in <code>$EBROOTHDF5/lib</code>, and so on.
Similarly, if a package depends on a library that is provided by a module other than <code>gentoo</code>, you may need to provide the location of the header files and libraries of that module. Those other modules also provide an environment variable that starts with EBROOT and ends with the capitalized module name. For example, after you issue the command <code>module load hdf5</code>, you can find its installation in <code>$EBROOTHDF5</code>, its header files in <code>$EBROOTHDF5/include</code>, its library files in <code>$EBROOTHDF5/lib</code>, and so on.


<!--T:13-->
<!--T:13-->
If a header file or library that would usually be provided by an RPM or other package manager in a typical Linux distribution is neither present via <code>nixpkgs</code> or via another module, please let us know. Most likely it can be easily added to the existing stack.
If a header file or library that would usually be provided by an RPM or other package manager in a typical Linux distribution is neither present via <code>gentoo</code> or via another module, please let us know. Most likely it can be easily added to the existing stack.


<!--T:14-->
<!--T:14-->
Notes:
Notes:
* all binaries under <code>/cvmfs/soft.computecanada.ca</code> use what is called a RUNPATH, which means that the directories for the runtime libraries that these binaries depend on are put inside the binary. That means it is generally '''not''' necessary to use <code>$LD_LIBRARY_PATH</code>. In fact, <code>$LD_LIBRARY_PATH</code> overrides this runpath and you should '''not''' set that environment variable to locations such as <code>/usr/lib64</code> or <code>$EBROOTNIXPKGS/lib</code>. Many binaries will no longer work if you attempt this.
* all binaries under <code>/cvmfs/soft.computecanada.ca</code> use what is called a RUNPATH, which means that the directories for the runtime libraries that these binaries depend on are put inside the binary. That means it is generally '''not''' necessary to use <code>$LD_LIBRARY_PATH</code>. In fact, <code>$LD_LIBRARY_PATH</code> overrides this runpath and you should '''not''' set that environment variable to locations such as <code>/usr/lib64</code> or <code>$EBROOTGENTOO/lib64</code>. Many binaries will no longer work if you attempt this.
* if all else fails you can use <code>module --force purge</code> to remove the CVMFS environment. You are then left with a bare-bones CentOS-7 installation without modules. This may help for special situations such as compiling GCC yourself or using custom toolchains such as the [http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk MESA SDK]. Purging modules would then '''only''' be necessary when you compile such software; the modules can be reloaded when running it.
* if all else fails you can use <code>module --force purge</code> to remove the CVMFS environment. You are then left with a bare-bones CentOS-7 installation without modules. This may help for special situations such as compiling GCC yourself or using custom toolchains such as the [http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk MESA SDK]. Purging modules would then '''only''' be necessary when you compile such software; the modules can be reloaded when running it.


Bureaucrats, cc_docs_admin, cc_staff, rsnt_translations
2,807

edits

Navigation menu