Bug 2314879
| Summary: | Rust 1.81+ implicitly / automatically sets soname on cdylib targets | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fabio Valentini <decathorpe> |
| Component: | rust | Assignee: | Josh Stone <jistone> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | amulhern, code, igor.raits, jistone, mhroncok, rust-sig, TicoTimo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rust-1.81.0-4.fc42 rust-1.81.0-4.fc41 rust-1.81.0-4.fc40 rust-1.81.0-4.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-10-08 02:02:27 UTC | 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: | |||
The following commit looks like it *could* be responsible: - It was first released in Rust 1.81 - It contains changes to shared-library/dylib linking, including SONAMEs https://github.com/rust-lang/rust/commit/565ddfb48ca2a3b24236c2b393ec14eb86d64a7a FEDORA-2024-f5e48710f6 (rust-1.81.0-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f5e48710f6 FEDORA-2024-f353abeb4a (rust-1.81.0-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f353abeb4a FEDORA-2024-f353abeb4a has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f353abeb4a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f353abeb4a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-70c557d9af has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-70c557d9af` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-70c557d9af See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-f5e48710f6 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f5e48710f6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f5e48710f6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-f5e48710f6 (rust-1.81.0-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-f353abeb4a (rust-1.81.0-4.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-70c557d9af (rust-1.81.0-4.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. |
Description of problem: ======================= We found that recent builds of Python modules with "native" Rust cores (i.e. using PyO3, built with setuptools_rust or maturin) started getting RPM provides for their soname, which is not intended or wanted. Looking back through build logs (and trying to build with older versions of maturin), we determined that the only likely suspect responsible for this change is the update from Rust 1.80 to 1.81, and that something in the build process is now setting the SONAME header in cdylib targets where previously this didn't happen without *explcitly* doing so (via build.rs script or external tools). This causes RPM to improperly generate Provides for this shared object / .so file where previously no such metadata was added automatically. Looking at other Python packages that ship native modules, having an SONAME ELF header set is not expected for .so files like this, since they are *dynamically loadable plugins* and not expected to be linked with at all. Version-Release number of selected component (if applicable): ============================================================= "good": rust-1.80.1-1.fc41 "bad": rust-1.81.0-1.fc42 How reproducible: ================= These packages all appear to be affected: - python-cramjam - python-cryptography - python-nh3 - python-orjson - python-pendulum - python-pydantic-core - python-rpds-py - python-watchfiles Builds with Rust 1.80 did *not* have an SOANME ELF header, but builds with Rust 1.81 do. Steps to Reproduce: =================== 1. build one of the affected packages with Rust 1.81 on Fedora (Rawhide) 2. see soname being set, and RPM generating Provides for the shared object, i.e. like "Provides: libcryptography_rust.so()(64bit)" Actual results: =============== The SONAME elf header is implicitly / automatically set Expected results: ================= The SONAME elf header is *not* implicitly / automatically set, and continues to require the user to use a build.rs script to do this ("rustc-cdylib-link-arg"), use the "cdylib-link-lines" crate, or use the cargo-c tool. Additional info: ================ Making it easier to set the SONAME of cdylib .so objects produced by rustc / cargo is welcome, but this looks like an unintentional behaviour change instead.