From 749c45343c6341632c88f18034e149325afc02e9 Mon Sep 17 00:00:00 2001 From: ocaisa Date: Thu, 12 Dec 2024 16:28:25 +0100 Subject: [PATCH] Update building_on_eessi.md --- docs/using_eessi/building_on_eessi.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/using_eessi/building_on_eessi.md b/docs/using_eessi/building_on_eessi.md index 0d895d113..4b8f1db84 100644 --- a/docs/using_eessi/building_on_eessi.md +++ b/docs/using_eessi/building_on_eessi.md @@ -82,7 +82,7 @@ Now, you are ready to build. For example, suppose you want to install `netcdf4-p eb netcdf4-python-1.6.5-foss-2023b.eb ``` -!!! Note +!!! note If this netCDF for python module is available by the time you are trying, you can force a local rebuild by adding the `--rebuild` argument in order to experiment with building locally, or pick a different EasyConfig to build. ### Using the newly built module @@ -151,7 +151,10 @@ shell before building. To do this: * Run! -!!! Note RPATH should never point to a compatibility layer directory, only to software layer ones, as all resolving is done via the runtime linker (`ld-linux*.so`) that is shipped with EESSI, which automatically searches these locations. +!!! warning + + RPATH should never point to a compatibility layer directory, only to software layer ones, as all resolving is done via the runtime linker (`ld-linux*.so`) + that is shipped with EESSI, which automatically searches these locations. The biggest downside of this approach is that your executable becomes bound to the architecture you linked your libraries for, i.e., if you add to your executable RPATH a `libhdf5.so`compiled for `intel_avx512`, you will not be able to run that binary on a machine with a different architecture. If this is an issue for you, you should look into how EESSI itself organises the location of binaries and perhaps leverage the relevant environment variables (e.g., `EESSI_SOFTWARE_SUBDIR`).