Deployed f300187 with MkDocs version: 1.6.1

EESSI · Dec 12, 2024 · 1c734d9 · 1c734d9
1 parent b5e0a99
commit 1c734d9
Show file tree

Hide file tree

Showing 2 changed files with 6 additions and 2 deletions.
diff --git a/search/search_index.json b/search/search_index.json
diff --git a/using_eessi/building_on_eessi/index.html b/using_eessi/building_on_eessi/index.html
@@ -2162,7 +2162,11 @@ <h2 id="manually-building-software-op-top-of-eessi-without-easybuild">Manually b
 <p>Run! </p>
 </li>
 </ul>
-<p>!!! Note RPATH should never point to a compatibility layer directory, only to software layer ones, as all resolving is done via the runtime linker (<code>ld-linux*.so</code>)  that is shipped with EESSI, which automatically searches these locations.</p>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
+<p>RPATH should never point to a compatibility layer directory, only to software layer ones, as all resolving is done via the runtime linker (<code>ld-linux*.so</code>)
+that is shipped with EESSI, which automatically searches these locations.</p>
+</div>
 <p>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 <code>libhdf5.so</code>compiled for <code>intel_avx512</code>, 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., <code>EESSI_SOFTWARE_SUBDIR</code>).</p>