Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

This command modifies the modules environment itself and adds $HOME/privatemodules to the path, where available modules modulefiles are searched for. Here you may place your own modulefiles to streamline a private software pool. It is also possible to manage the environment variable for different tasks this way.

Compiling and linking installed libraries using modules

The modified environmental variables can be used by compilers, linkers, make, cmake or private software installation tools, to recognise details of installed libraries and link them accordinglyMany software at HLRN depends on installed libraries like the MPI-libraries, fftw3, blas, netcdf or hdf5. On a PC, those libraries and headers would reside at well defined places in the system, where the are found by the compiler and linker and also by the loader during runtime. At HLRN, several versions of those libraries are available. They must be installed at non-default places. So compiler, linker and loader need help to find them, especially the correct version. The dream of software users is that loading a module is all to be done to deliver this help. Unfortunately, this is not the case for several reasons.

Compilers and linkers use some well defined environmental variables to serve or get information on libraries. Typical examples are PATH, LD_RUNPATH, LD_LIBRARY_PATH, LIBRARY_PATH or PKG_CONFIG_PATH.. If those may be usefull, they are set or modified, if a module is loaded. To see, how a package is installed and which environmental variables are delivereddefined, use

       module show <package>/<version>

However, for building complex software, build-tools like autotools or cmake are used, which come with own rules, how information on to be linked libraries has to be delivered. In turn, the netcdf library uses nc-config and nf-config to deliver the information on the path to the netcdf headers and libraries. All serious build tools use this option and a netcdf-module just needs to deliver the path (PATH) to these tools. Very specific is cmake that searches for libraries instead of requesting information in a well defined way. This does not fit well in the philosophy of environment modules there may be cases, where only the documentation on the to be build software helps.

Another issue may be that successfully linked libraries are not found when running the executable. One may be tempted to load the related module again. However, in most cases this does not help to overcome the problem, many modules do not have any effect during runtime. Here the solution is to avoid overlinking and to burn the path to the libraries into the executable. Read more on linking hdf5 and netcdf libraries with the help of the related environment modules.