What were you trying to do that didn't work?

Build netcdf in EPEL10.  Tests fail with:

 /builddir/build/BUILD/netcdf-c-4.9.2/build/ncgen3/.libs/lt-ncgen3: error  while loading shared libraries: libnetcdf.so.19: cannot open shared  object file: No such file or directory

What is the impact of this issue to you?

I can work around this, but it just seems wrong

Please provide the package NVR for which the bug is seen:

2.4.7-12.el10

How reproducible is this bug?:

Every time

Steps to reproduce

1. build the rawhide branch of netcdf in epel10

Expected results

Tests run fine

I believe this is the culprit:

— fedora-rawhide-x86_64/root/builddir/build/BUILD/netcdf-4.9.2-build/netcdf-c-4.9.2/build/libtool     2024-10-29 20:40:32.996721304 -0600
+++ centos-stream+epel-10-x86_64/root/builddir/build/BUILD/netcdf-c-4.9.2/build/libtool 2024-10-29 20:35:41.753975205 -0600

 # Whether or not to optimize for fast installation.
-fast_install=needless
+fast_install=yes

 # Is shlibpath searched before the hard-coded library search path?
-shlibpath_overrides_runpath=yes
+shlibpath_overrides_runpath=no

From https://www.gnu.org/software/libtool/manual/libtool.html

Variable: shlibpath_overrides_runpath

    Indicates whether it is possible to override the hard-coded library search path of a program with an environment variable. If this is set to no, libtool may have to create two copies of a program in the build tree, one to be installed and one to be run in the build tree only. When each of these copies is created depends on the value of fast_install. The default value is ‘unknown’, which is equivalent to ‘no’. 

This appears to be the difference that I'm seeing.  It also seems to just be wrong.

There is no (real) difference between the libtool.spec file in rawhide and 10-stream.  I can't find any public build logs though for centos stream builds.

It's also very strange that this is the first package I've built that has had this issue.