SDDS, elegant, etc. RHEL9 RPMs are broken
Posted: 29 Oct 2024, 11:26
Hello all,
I have run into a very unexpected problem. RedHat shipped RHEL9.3 with an blas/lapac setup that essentially makes it impossible to have the blas-devel and lapack-devel libraries installed and still be able to use the non-64-bit integer versions of blas and lapack. This was not the case on earlier version of RHEL. For example, blas-devel and lapack-devel == v3.9.0-8 did not require blas64 or lapack64 be installed. blas64 and lapack64 ship with a mismatched SONAME that poisons ldconfig and generates the wrong SO symlink in /lib64.
I'm not sure if these are publicly available, but I have support case #03717080 open about the issue. I just updated it with new information, but, prior to that, the assumption was that RedHat was refusing to fix the problem with blas64 and lapack64. We'll see if they decide to at least roll the dependency change back.
At the very least, I would like you to know that most (all?) of the RPMs you ship that require blas/lapack currently don't work on more recent versions of RHEL9. I manage the controls environment for a facility who's operations team uses your software to for beam operations. I see to basic paths forward at the moment. You could release versions that use blas64/lapack64. I'm not sure of the meaningful differences between 64 and non64 versions other than integer precision. The other alternative is that end users would need to apply some hacky fixes to make things work (e.g., manual edit SONAMEs in compiled objects or playing games with LD_LIBRARY_PATH).
An easy way to test this is to run sddspseudoinverse or any similar command on an updated RHEL9 box with lapack64/blas64 installed.
Thank you for your help!
I have run into a very unexpected problem. RedHat shipped RHEL9.3 with an blas/lapac setup that essentially makes it impossible to have the blas-devel and lapack-devel libraries installed and still be able to use the non-64-bit integer versions of blas and lapack. This was not the case on earlier version of RHEL. For example, blas-devel and lapack-devel == v3.9.0-8 did not require blas64 or lapack64 be installed. blas64 and lapack64 ship with a mismatched SONAME that poisons ldconfig and generates the wrong SO symlink in /lib64.
I'm not sure if these are publicly available, but I have support case #03717080 open about the issue. I just updated it with new information, but, prior to that, the assumption was that RedHat was refusing to fix the problem with blas64 and lapack64. We'll see if they decide to at least roll the dependency change back.
At the very least, I would like you to know that most (all?) of the RPMs you ship that require blas/lapack currently don't work on more recent versions of RHEL9. I manage the controls environment for a facility who's operations team uses your software to for beam operations. I see to basic paths forward at the moment. You could release versions that use blas64/lapack64. I'm not sure of the meaningful differences between 64 and non64 versions other than integer precision. The other alternative is that end users would need to apply some hacky fixes to make things work (e.g., manual edit SONAMEs in compiled objects or playing games with LD_LIBRARY_PATH).
An easy way to test this is to run sddspseudoinverse or any similar command on an updated RHEL9 box with lapack64/blas64 installed.
Thank you for your help!