Bug 650645 - Cannot Create a shared object while using LibRaw on x86_64
Summary: Cannot Create a shared object while using LibRaw on x86_64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: LibRaw
Version: 13
Hardware: x86_64
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Siddhesh Poyarekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-07 15:28 UTC by Nicolas Chauvet (kwizart)
Modified: 2015-09-14 00:22 UTC (History)
2 users (show)

Fixed In Version: LibRaw-0.9.1-9.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-22 22:21:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicolas Chauvet (kwizart) 2010-11-07 15:28:38 UTC
Description of problem:
One cannot use LibRaw.a on x86_64 because of bad compilation options.

Version-Release number of selected component (if applicable):
LibRaw-devel-0.9.1-8.fc13.x86_64 (current from f13 to devel).

How reproducible:
always.

Steps to Reproduce:
1. yumdownloader --source oyranos
2. yum install LibRaw-devel
3. yum-builddeps oyranos*.src.rpm
4. rpmbuild --rebuild oyranos*.src.rpm
  
Actual results:
/usr/bin/ld: /usr/lib64/libraw.a(libraw_cxx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/libraw.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [liboyranos_lraw_cmm_module.so.0.1.12] Error 1

Expected results:
It should link library to build oyranos shared object.

Additional info:

There is a need to conveince upstream to use a shared library model specially for huges library.

Comment 1 Siddhesh Poyarekar 2010-11-08 10:41:57 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.

Comment 2 Siddhesh Poyarekar 2010-11-13 17:38:29 UTC
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.

Comment 3 Fedora Update System 2010-11-13 18:00:58 UTC
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

Comment 4 Fedora Update System 2010-11-13 18:01:04 UTC
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

Comment 5 Fedora Update System 2010-11-14 21:27:38 UTC
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

Comment 6 Nicolas Chauvet (kwizart) 2010-11-15 14:16:30 UTC
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).

Comment 7 Siddhesh Poyarekar 2010-11-15 14:40:30 UTC
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.

Comment 8 Fedora Update System 2010-11-22 22:20:56 UTC
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.

Comment 9 Fedora Update System 2010-11-22 22:24:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.