Bug 650645
| Summary: | Cannot Create a shared object while using LibRaw on x86_64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Chauvet (kwizart) <kwizart> |
| Component: | LibRaw | Assignee: | Siddhesh Poyarekar <spoyarek> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | mnewsome, spoyarek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | LibRaw-0.9.1-9.fc13 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-22 22:21:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nicolas Chauvet (kwizart)
2010-11-07 15:28:38 UTC
Upstream has already said that they are not interested in a shared library model since they do not want the overhead of vesioning symbols or maintaining ABI compatibility across releases. I'll try out this build in a couple of days and see if I can find out what the root cause is. Ok, I have put out a build in rawhide with -fPIC, which should work well with your lib. I'll build and push for F-14 and F-13 as well. LibRaw-0.9.1-9.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/LibRaw-0.9.1-9.fc13 LibRaw-0.9.1-9.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/LibRaw-0.9.1-9.fc14 LibRaw-0.9.1-9.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update LibRaw'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/LibRaw-0.9.1-9.fc13 Hi,
Thx for the update.
Once that said, fixing the problem by using -fPIC on a static library is quite annoying. Because at the end it is in-between a static and shared library.
The upstream concern not to care about ABI might be legitimate, their solution to build only a static library is unrelated to the problem.
In our case, it seems much better to enforce the build of a shared library with a specific SONAME and to provide a RPM macro so a dependant package can require the exact version of the said library.
This is somehow what is done with qt-devel providing %{_qt4_version} so that packages using qt-devel can use Requires: qt4%{?_isa} >= %{_qt4_version}. That will ensure that the qt version required at runtime will always be equal or higher than the qt version used to build the package.
(In the case of a static > shared conversion it will have to be stricly equal).
Upstream choosing to ship a static library is definitely unrelated to this bug, since the bug is about the object code in the library being built without fPIC. Upstream can choose to not care about backward ABI compatibility, but it will hurt us since I will then have to make sure that any updates that break ABI are not applied since it will break all applications that use the library. Sure, I can simply ask the maintainers to do a mass rebuild, but that is quite cumbersome if it is going to happen all the time. I know that the problem remains that way with static libraries also but since maintaining an extra patch for Fedora is not going to help me at all, I don't find it worth the effort. LibRaw-0.9.1-9.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. LibRaw-0.9.1-9.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |