cc_staff
91
edits
Installing software in your home directory: Difference between revisions
Jump to navigation
Jump to search
m
Installing software in your home directory (view source)
Revision as of 16:08, 7 July 2017
, 6 years agofixed layout
(added note about setrpaths.sh) |
m (fixed layout) |
||
| Line 51: | Line 51: | ||
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>$EBROOTNIXPKGS/lib</code>. Many binaries will no longer work if you attempt this. | ||
* if you install precompiled binaries in your home directory (for example [https://conda.io/miniconda.html Miniconda]) they may fail using errors such as <code>/lib64/libc.so.6: version `GLIBC_2.18' not found</code>. Often such binaries can be patched using our <code>setrpaths.sh</code> script, using the syntax <code>setrpaths.sh | * if you install precompiled binaries in your home directory (for example [https://conda.io/miniconda.html Miniconda]) they may fail using errors such as <code>/lib64/libc.so.6: version `GLIBC_2.18' not found</code>. Often such binaries can be patched using our <code>setrpaths.sh</code> script, using the syntax <code>setrpaths.sh --path path [--add_origin]</code> where path refers to the directory where you installed that software. This script will make sure that the binaries use the correct interpreter, and search for the libraries they are dynamically linked to in the correct folder. The option <code>--add_origin</code> will also add $ORIGIN to the RUNPATH. This is sometimes helpful if the library cannot find other libraries in the same folder as itself. | ||
--path path [--add_origin]</code> where path refers to the directory where you installed that software. This script will make sure that the binaries use the correct interpreter, and search for the libraries they are dynamically linked to in the correct folder. The option <code>--add_origin</code> will also add $ORIGIN to the RUNPATH. This is sometimes helpful if the library cannot find other libraries in the same folder as itself. | |||
* 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. | ||
</translate> | </translate> | ||