Bug 2001328

Summary: missing call to ldconfig in RPM scriptlets
Product: [Fedora] Fedora Reporter: Fabio Valentini <decathorpe>
Component: llvm12Assignee: Tom Stellard <tstellar>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: sguelton, tstellar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabio Valentini 2021-09-05 14:48:38 UTC
llvm12 installs a config snippet to /etc/ld.so.conf.d/ to add the compat libraries for llvm 12 into the search path.

Packages that do this still need to explicitly call ldconfig in their RPM scriptlets, because file triggers do only activate for installing things into %{_libdir} directly.

The "%ldconfig_scriptlets" macro does not help in this case, because it expands to an empty string on all current Fedora releases, so this probably needs to be handled "manually" / the old way with an explicit %pre/post/trans/un scriptlet.

This issue manifests only in some cases (I think probably depending on the exact installation order in an RPM transaction), but if it happens, this missing ldconfig call results in programs not being able to find llvm 12 libraries, for example, rustc sometimes fails with this error:

error: process didn't exit successfully: `/usr/bin/rustc -vV` (exit status: 127)
--- stderr
/usr/bin/rustc: error while loading shared libraries: libLLVM-12.so: cannot open shared object file: No such file or directory

Running "ldconfig" manually in the mock chroot makes this error go away, until the mock chroot is cleaned and reinstalled, and then it happens again.

(I'm not sure why this is the case, but this error only happens in mock builds that use QEMU-emulated s390x chroots, both locally, and in COPR, but not consistently. koji does not seem to be affected at all, so maybe this is impacted by a race condition, as well.)

Comment 1 Ben Cotton 2022-02-08 21:41:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 2 Ben Cotton 2023-04-25 16:44:26 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 3 Fabio Valentini 2023-04-25 17:02:33 UTC
This issue is still present in rawhide.

Comment 4 Fedora Release Engineering 2023-08-16 07:04:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.