On 10/29/24 22:32, Orion Poplawski wrote:
On 10/27/24 20:17, Orion Poplawski wrote:I'm trying to build netcdf in EPEL10 but the test suite is failing to run 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 directoryComparing EPEL10 to rawhide builds I notice that while the EPEL10 build produces an "lt-ncgen3" binary, rawhide does not. The rawhide ncgen3 wrapper script appears to set LD_LIBRARY_PATH, the EPEL10 one does not and instead seems to try to produce a "relinked" file.I don't think I have every run into this issue before and have no idea why it's happening.Any libtool experts out there with an idea?Some more differences:--- 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_runpathIndicates 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.I've filed https://issues.redhat.com/browse/RHEL-65261
The issue appears to be caused by the rpath workaround from here: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_removing_rpathsed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtoolRemoving that from the netcdf package allows the tests to run. Still need to confirm that rpath does not return without it though.
-- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxx Boulder, CO 80301 https://www.nwra.com/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
