List GLIBC version requirements in Release Notes #14371

spfeiffer1 · 2025-03-14T15:30:51Z

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.

rmcdermo · 2025-03-14T15:36:47Z

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?

spfeiffer1 · 2025-03-14T15:46:38Z

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

rmcdermo · 2025-03-14T15:48:01Z

Please show what you added to your .bashrc

marcosvanella · 2025-03-14T15:49:34Z

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.

spfeiffer1 · 2025-03-14T15:56:58Z

oops! i apologise for the formatting from #.

rmcdermo · 2025-03-14T16:05:06Z

@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)

johodges · 2025-03-14T16:16:13Z

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.

johodges · 2025-03-14T16:24:21Z

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.

gforney · 2025-03-14T16:55:31Z

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

johodges · 2025-03-14T17:04:20Z

I can try to play around with it with patchelf. Can you add your linker library as well?

ld-linux.so.2

gforney · 2025-03-14T17:24:58Z

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?

johodges · 2025-03-14T17:27:44Z

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.

gforney · 2025-03-14T17:32:26Z

I added it to the same place where I put the tar file

johodges · 2025-03-14T17:47:56Z

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.

johodges · 2025-03-14T19:03:12Z

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.

spfeiffer1 · 2025-03-14T19:12:49Z

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

johodges · 2025-03-14T19:17:20Z

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

cxp484 · 2025-03-14T19:24:58Z

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.

spfeiffer1 · 2025-03-14T19:37:55Z

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?

mcgratta · 2025-03-14T19:47:03Z

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.

drjfloyd · 2025-03-14T19:53:09Z

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.

mcgratta · 2025-03-14T20:04:53Z

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?

cxp484 · 2025-03-14T20:13:38Z

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.

johodges · 2025-03-14T20:14:57Z

@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.

gforney · 2025-03-14T20:38:15Z

@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

johodges · 2025-03-14T20:50:12Z

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?

mpiTest.txt

johodges · 2025-03-14T21:50:07Z

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

patch_fds.txt

spfeiffer1 · 2025-03-17T14:41:12Z

@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.

johodges · 2025-03-17T14:43:55Z

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

spfeiffer1 · 2025-03-17T15:39:50Z

@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

johodges · 2025-03-17T15:44:59Z

It looks like the installed FDS directory was added to your PATH or LD_LIBRARY_PATH (possibly from sourcing FDS6VARS.sh). When I ran into this issue I removed all definitions to the LD_LIBRARY_PATH and it loaded fine. Try unsetting the LD_LIBRARY_PATH and then re-run the patch:

export LD_LIBRARY_PATH=

We are telling FDS to run with a different linker program, and if that is added to your LD_LIBRARY_PATH the machine will try to use that linker for all of your default linux commands which will break them (like ls, pwd, tar, etc.).

spfeiffer1 · 2025-03-17T15:55:21Z

ok we are getting somewhere?? :)

[pfeiffes@athenatds mpitest]$ mpiexec -np 3 fds mpiTest.txt
Segmentation fault (core dumped)

johodges · 2025-03-17T15:57:34Z

Is patchelf installed on the machine? Did any errors occur in the patchelf command?

which patchelf

spfeiffer1 · 2025-03-17T16:03:27Z

~/python/env/3.9.7/bin/patchelf
No errors occured in the patchelf command

johodges · 2025-03-17T16:41:46Z

A few follow-ups.

Can you check which mpiexec is being pulled in?

which mpiexec

This should be pointing to:

FDS/FDS6/bin/INTEL/bin/mpiexec

Then navigate to that directory (FDS/FDS6/bin/INTEL/bin/) and run readelf to see the rpath that is set in the file:

readelf -d mpiexec | grep PATH

That should yield something like this:

0x000000000000000f (RPATH) Library rpath: [/home/jhodges/FDS/FDS6/bin/INTEL/lib/]

Then do something similar with the fds executable:

which fds

Navigate to the directory (FDS/FDS6/bin) and run readelf:

readelf -d fds| grep PATH

Which should yield something like this:

0x000000000000000f (RPATH) Library rpath: [/home/jhodges/FDS/FDS6/bin/INTEL/lib/:/usr/lib64]

spfeiffer1 · 2025-03-17T16:57:23Z

Here are my results

[pfeiffes@athenatds mpitest]$ which mpiexec
~/FDS/FDS6/bin/INTEL/bin/mpiexec

[pfeiffes@athenatds bin]$ readelf -d mpiexec | grep PATH
0x000000000000000f (RPATH) Library rpath: [/athena/home/pfeiffes/FDS/FDS6/bin/INTEL/lib/]

[pfeiffes@athenatds bin]$ which fds
~/FDS/FDS6/bin/fds

[pfeiffes@athenatds bin]$ readelf -d fds| grep PATH
0x000000000000000f (RPATH) Library rpath: [/athena/home/pfeiffes/FDS/FDS6/bin/INTEL/lib/:/usr/lib64]

johodges · 2025-03-17T17:22:25Z

All that looks fine to me. It might be better if we can have a call to work through the issue. You can send me an email at [email protected] and we can coordinate from there.

mcgratta assigned johodges Mar 17, 2025

List GLIBC version requirements in Release Notes #14371

List GLIBC version requirements in Release Notes #14371

Comments

spfeiffer1 commented Mar 14, 2025

rmcdermo commented Mar 14, 2025

spfeiffer1 commented Mar 14, 2025

rmcdermo commented Mar 14, 2025

marcosvanella commented Mar 14, 2025

spfeiffer1 commented Mar 14, 2025

rmcdermo commented Mar 14, 2025

johodges commented Mar 14, 2025

johodges commented Mar 14, 2025

gforney commented Mar 14, 2025

johodges commented Mar 14, 2025

gforney commented Mar 14, 2025

johodges commented Mar 14, 2025

gforney commented Mar 14, 2025

johodges commented Mar 14, 2025

johodges commented Mar 14, 2025 • edited Loading

spfeiffer1 commented Mar 14, 2025

johodges commented Mar 14, 2025

cxp484 commented Mar 14, 2025 • edited Loading

spfeiffer1 commented Mar 14, 2025

mcgratta commented Mar 14, 2025

drjfloyd commented Mar 14, 2025

mcgratta commented Mar 14, 2025

cxp484 commented Mar 14, 2025

johodges commented Mar 14, 2025

gforney commented Mar 14, 2025

johodges commented Mar 14, 2025

johodges commented Mar 14, 2025 • edited Loading

spfeiffer1 commented Mar 17, 2025

johodges commented Mar 17, 2025

spfeiffer1 commented Mar 17, 2025

johodges commented Mar 17, 2025

spfeiffer1 commented Mar 17, 2025

johodges commented Mar 17, 2025

spfeiffer1 commented Mar 17, 2025

johodges commented Mar 17, 2025

spfeiffer1 commented Mar 17, 2025

johodges commented Mar 17, 2025

johodges commented Mar 14, 2025 •

edited

Loading

cxp484 commented Mar 14, 2025 •

edited

Loading

johodges commented Mar 14, 2025 •

edited

Loading