firemodels
List GLIBC version requirements in Release Notes
It would be very helpful if you could a what glibc version that fds needs in your release notes as it saves a lot of time from downloading and installing and then when we run the code, we find out that it needs a newer version of GLIBC and my OS does not have it. Thank you.
We try to include any necessary libraries in the bundle. So, we would need you to provide more information about what your problem is. Which OS are you using? What error are you getting exactly?
OS: CentOS Linux release 8.2.2004 fds version 6.10.0 from https://pages.nist.gov/fds-smv/downloads.html
I've tried to install 6.10.0 on the Linux cluster. However, I get the following after I try to install and run fds:
fds: /usr/lib64/libc.so.6: version `GLIBC_2.34' not found (required by fds)
My system only has glibc-2.28-101.el8.x86_64 glibc-2.28-101.el8.i686
That is the glibc version we have in the cluster where we build the linux bundle:
mnv@spark-login Tests_2D (master) $ ldd --version ldd (GNU libc) 2.34 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.
I'll add the version in the release notes.
@gforney @mcgratta I thought we tried to add all necessary libraries to the bundle. It looks like we are not including the /usr/lib64/ requirements. When I do ldd ./fds I get
(fds_python_env) rmcdermo@spark-login bin $ ldd ./fds
linux-vdso.so.1 (0x00007ffc08dfb000)
libimf.so => /home/rmcdermo/FDS/FDS-6.10.0_SMV-6.10.0/bin/INTEL/lib/libimf.so (0x000014960f1ec000)
libm.so.6 => /usr/lib64/libm.so.6 (0x000014960f111000)
libmpifort.so.12 => /home/rmcdermo/FDS/FDS-6.10.0_SMV-6.10.0/bin/INTEL/lib/libmpifort.so.12 (0x000014960ed1c000)
libmpi.so.12 => /home/rmcdermo/FDS/FDS-6.10.0_SMV-6.10.0/bin/INTEL/lib/libmpi.so.12 (0x0000149604d56000)
libc.so.6 => /usr/lib64/libc.so.6 (0x0000149604a00000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x0000149604d3a000)
libintlc.so.5 => /home/rmcdermo/FDS/FDS-6.10.0_SMV-6.10.0/bin/INTEL/lib/libintlc.so.5 (0x0000149604cd8000)
/lib64/ld-linux-x86-64.so.2 (0x000014960f5fa000)
librt.so.1 => /usr/lib64/librt.so.1 (0x0000149604cd3000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000149604cce000)
This is the issue I had mentioned a few weeks ago on the dev call. The latest mpiifx added a requirement for glibc 2.34 which breaks compatibility with older linux machines. I am compiling 6.10 on our cluster with openmpi instead until we get it upgraded.
It would be great if we can bundle glibc as well, but I don't know if that is possible. It is one of the fundamental libraries of the kernel which is why it is hard to upgrade without updating the full OS. There are some commands you can use to try and preload different versions of it, but I haven't had a lot of success with those.
Centos 6 hit EOL in 2020 so all the repos are down now, so I wouldn't stress too much about trying to continue to support this OS. GLIBC 2.34 is fairly recent (~2021) so it may affect some other active distributions as well, but the ones that haven't hit EOL should still be able to upgrade to a more recent glibc.
I copied most of the run time libraries that fds references on our system and tar'd them up. try the following
-
go to https://github.com/firemodels/test_bundles/releases/tag/FDS_TESTand download the file lib_rt_6.10.0.tar
-
on your linux computer, cd to the directory where the lib files are located on my system cd $HOME/FDS/FDS6/bin/INTEL you should see the following bin lib prov version
-
mv the lib directory by typing mv lib libBAK
-
copy the tar file to the $HOME/FDS/FDS6/bin/INTEL directory and type
tar xvf lib_rt_6.10.0.tar
now you should see
bin lib libBAK lib_rt_6.10.0.tar prov version
- now try running fds
not sure how and older OS will handle libraries from a new OS - so don't know if this will work but give it a try
I can try to play around with it with patchelf. Can you add your linker library as well?
ld-linux.so.2
I don't see ld-linux.so.2 on our system but I do see /usr/lib64/ld-linux-x86-64.so.2 would this work for you or where would you expect to find it?
Yep, that should be the one. If I am re-linking libraries in the executable, I need to use the same linker that was used during compilation.
This might work for some users, but it did not work on our cluster:
- Download and install FDS as usual
- Navigate to the intel lib, FDS/FDS6/bin/INTEL
- Backup the lib directory: mv lib libBAK
- Download lib_rt_6.10.0.tar and ld-linux-x86-64.so.2 from https://github.com/firemodels/test_bundles/releases/tag/FDS_TEST
- untar lib_rt_6.10.0.tar into FDS/FDS6/bin/INTEL/lib
- Move ld-linux-x86-64.so.2 into FDS/FDS6/bin/INTEL/lib
- Change the permissions on the linker file: chmod +x ld-linux-x86-64.so.2
- Execute the linker command before the fds call and specify the library path to INTEL/lib
. /path/to/FDS/FDS6/bin/INTEL/lib/ld-linux-x86-64.so.2 --library-path /path/to/FDS/FDS6/bin/INTEL/lib/ /path/to/FDS/FDS6/bin/fds
This process worked for me to use the updated library path on a newer machine. On our cluster I get the cryptic error:
FATAL: kernel too old
It might be possible to get past that as well, but I'll have to look into it more. I haven't seen that error before.
How important is it that we build the release with the latest oneapi? I can build the current FDS source and run on our cluster with the 2024.0 oneapi. Not to say that is a permanent solution, but if we wanted to have a release that would not have this issue until we decide on the permanent solution.
Hi @johodges ,
I tried your instructions (not sure if it was for me to test or not). But I was curious.
When I ran ./fds, I got the following ./fds: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
You'll need to run the linker library first. Here is the command on my machine:
/home/jhodges/FDS/FDS6/bin/INTEL/lib/ld-linux-x86-64.so.2 --library-path /home/jhodges/FDS/FDS6/bin/INTEL/lib/ /home/jhodges/FDS/FDS6/bin/fds
The message on your end indicates that you didn't set the --libary-path
I did a quick ChatGPT-based research on the RHEL release versions and their corresponding GLIBC versions. Below is a summary:
RHEL Version | glibc Version | Release Year RHEL 7.0 2.17 2014 RHEL 7.1 2.17 2015 RHEL 7.2 2.17 2015 RHEL 7.3 2.17 2016 RHEL 7.4 2.17 2017 RHEL 7.5 2.17 2018 RHEL 7.6 2.17 2018 RHEL 7.7 2.17 2019 RHEL 7.8 2.17 2020 RHEL 8.0 2.28 2019 RHEL 8.1 2.28 2019 RHEL 8.2 2.28 2020 RHEL 8.3 2.31 2020 RHEL 8.4 2.31 2021 RHEL 8.5 2.33 2021 RHEL 8.6 2.33 2022 RHEL 8.7 2.34 2022 RHEL 8.8 2.34 2023 RHEL 9.0 2.34 2022
A similar table for CentOS is:
CentOS Version | glibc Version | Release Year CentOS 7.0 2.17 2014 CentOS 7.1 2.17 2015 CentOS 7.2 2.17 2015 CentOS 7.3 2.17 2016 CentOS 7.4 2.17 2017 CentOS 7.5 2.17 2018 CentOS 7.6 2.17 2018 CentOS 7.7 2.17 2019 CentOS 7.8 2.17 2020 CentOS 8.0 2.28 2019 CentOS 8.1 2.28 2019 CentOS 8.2 2.28 2020 CentOS 8.3 2.31 2020 CentOS 8.4 2.31 2021 CentOS 8.5 2.33 2021 CentOS 8.6 2.33 2022 CentOS 8.7 2.34 2022
Note that the data above may be inaccurate for some versions, as I did not check the official OS release manual. However, it serves as a indication. Based on this, it seems that our release build is most likely compatible with CentOS 8.7 and onwards, as we are building with GLIBC-2.34. If we aim to support CentOS 8.2, we would either need to build using RHEL 8.2 or downgrade FDS build OS GLIBC to 2.28. The latter might be a difficult task based on certain articles I’ve read, though I’m not very sure.
Our Linux clusters are production servers that are used in a research national lab. We cannot just upgrade our OS for a software. It is a major task and involves many other scientific software.
It would be nice if you could have a copy that is compatible with GLIBC 2.28.
Meanwhile @johodges, I did follow your instructions to invoke the linker library:
/athena/opt/fds/6.10.0/bin/INTEL/lib/ld-linux-x86-64.so.2 --library-path /athena/opt/fds/6.10.0/bin/INTEL/lib/ /athena/opt/fds/6.10.0/bin/fds
Fire Dynamics Simulator
Current Date : March 14, 2025 15:31:51 Revision : FDS-6.10.0-0-g618ac07-release Revision Date : Fri Mar 7 12:12:25 2025 -0500 Compiler : Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.4 Build 20241205 Compilation Date : Mar 11, 2025 16:04:46
MPI version: 3.1 MPI library version: Intel(R) MPI Library 2021.14 for Linux* OS
Hypre library version: v2.32.0 Sundials library version: v6.7.0 Consult FDS Users Guide Chapter, Running FDS, for further instructions.
Then I ran fds ./fds ./fds: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
Am I doing something wrong?
Would it be possible to do a static build of FDS; that is, include all libs in the executable? I think we ruled this out long ago, but I cannot remember why.
glibc is a core system library not a compiler library. If your OS is too old you won't be able to simply install a new glibc.
I did a little research and found out why static linking has its own set of challenges that dwarf what we're dealing with now. But just so that I understand, does this mean that if your linux OS is too old, you cannot compile with the latest version of oneAPI?
I did a little research and found out why static linking has its own set of challenges that dwarf what we're dealing with now. But just so that I understand, does this mean that if your linux OS is too old, you cannot compile with the latest version of oneAPI?
If my understanding is correct, I think with an older OS, we can still compile FDS using the latest OneAPI, provided it can be installed. However, the main issue is that if the FDS executable is built on a newer OS, it may not run on an older OS if the GLIBC version on the older system is lower than the version required by the executable. For the 6.9.1 build, I guess we used Blaze, which likely had a relatively old GLIBC version, allowing it to support older OS versions without any issues. Currently, we are building the executable using RHEL 9.3, which has GLIBC 2.34.
@spfeiffer1 looks like my fix may work for your machine. Rather than calling fds, you would use the command that you used to test to call fds. I tried running with mpiexec as well but that didn't work. Based on the ldd mpiexec on my machine I expect we need "libpthread.so.0". If @gforney is able to provide that as well we may be able to get you going with mpi as well. Once we figure out how to set up the linker and libraries appropriately, we could probably simplify the run command from the user by patching the binary with pathelf to point it to the additional libraries Glenn provided. This is essentially making our own static build based on the libraries on NIST's machine.
@mcgratta that's correct. Our cluster and @spfeiffer1's cluster are both on CentOS6 which hit end of life in 2020. Parts of the GLIBC libraries the latest oneapi requires came out in 2021.
@cxp484 The slightly older mpiifx (2024.0) did not have that GLIBC dependency added so I can still use that on our cluster to compile. I don't think you would have been able to build with the latest oneapi on Blaze either.
@johodges I posted libpthread.so.0 in the same place . Once things are working I can build a new .tar file with all the needed files
That was the only missing file. I am able to run with mpiexec and the files you provided.
/home/jhodges/FDS/FDS6/bin/INTEL/lib/ld-linux-x86-64.so.2 --library-path /home/jhodges/FDS/FDS6/bin/INTEL/lib/ /home/jhodges/FDS/FDS6/bin/INTEL/bin/mpiexec -np 3 /home/jhodges/FDS/FDS6/bin/INTEL/lib/ld-linux-x86-64.so.2 --library-path /home/jhodges/FDS/FDS6/bin/INTEL/lib/ /home/jhodges/FDS/FDS6/bin/fds mpiTest.txt
@spfeiffer1 could you download the additional file gforney posted and add to your INTEL/lib directory then try to run the file I have below?
Here is a bash script which will patch the current test build of FDS-6.10.0 on a linux machine. The script does the following:
- Downloads the pre-compiled FDS and installs in /home/$USER/FDS
- Generates a back up of the mpiexec and fds executables as well as the INTEL/lib
- Downloads the tar and additional libraries that @gforney uploaded, extracts them to INTEL/lib, and changes permissions on them
- Patches the mpiexec and fds executables to use the new libraries in INTEL/lib
- Sets the FDS runtime environment (note it is a bit different than provided in FDS6VARS.sh)
- Creates an mpitest file and runs it in /home/$USER/mpitest
If everything works as expected the case should run 10 seconds of sim time with 3 cores. After patching, the run command is the same as normal without having to specify the linker or library directories.
mpiexec -np 3 fds mpiTest.txt
@johodges Hi, the patch_fds.txt file is pointing to https://github.com/firemodels/test_bundles/releases/download/FDS_TEST/FDS-6.10.0-12_SMV-6.10.0-18_test_lnx.sh. I don't have access to that file.
Sorry about that, I had it pointing to the current nightly bundle which has since been updated. Update that to point to the 6.10.0 release here which should not change.
https://github.com/firemodels/fds/releases/download/FDS-6.10.0/FDS-6.10.0_SMV-6.10.0_lnx.sh
@johodges I am getting this error when I untar lib_rt_6.10.0.tar symbol lookup error: /athena/home/pfeiffes/FDS/FDS6/bin/INTEL/lib/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE
and cannot proceed from there