Bug 126478 - Boost libs not compiled with -fPIC
Boost libs not compiled with -fPIC
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Benjamin Kosnik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-22 05:09 EDT by Jason Hill
Modified: 2013-08-09 01:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-02 11:22:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for boost.spec (986 bytes, patch)
2004-06-22 05:11 EDT, Jason Hill
no flags Details | Diff
More radical patch (407 bytes, patch)
2004-11-14 20:00 EST, Philippe Rigault
no flags Details | Diff

  None (edit)
Description Jason Hill 2004-06-22 05:09:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6)
Gecko/20040518 Firefox/0.8

Description of problem:
The boost libs in FC2 are not compiled with -fPIC.  This leads to all
sorts of headaches on x86-64 during linking, eg

thislib.a(thislib.o): relocation R_X86_64_32 can not be used when
making a shared object; recompile with -fPIC
thislib.a: could not read symbols: Bad value

Version-Release number of selected component (if applicable):
boost-1.31.0-7

How reproducible:
Always

Steps to Reproduce:
1.  Write code that uses boost libs
2.  Compile for x86-64 using boost shared libs
3.  Wait eons for g++ to finish
4.  Cringe at linker error
    

Actual Results:  thislib.a(thislib.o): relocation R_X86_64_32 can not
be used when making a shared object; recompile with -fPIC
thislib.a: could not read symbols: Bad value

Expected Results:  Happy linker with no errors

Additional info:
Comment 1 Jason Hill 2004-06-22 05:11:36 EDT
Created attachment 101324 [details]
Patch for boost.spec

Patch adds -fPIC compile options to .spec file.  Tested and works fine for
me(tm)
Comment 2 Philippe Rigault 2004-11-14 20:00:24 EST
Created attachment 106692 [details]
More radical patch

Bug confirmed on FC3 (boost-devel-1.31.0-9) 
 
Prevents compilation of KDE from sources. 
 
/usr/bin/ld: /usr/lib64/libboost_python.a(list.o): relocation 
R_X86_64_32 against `a local symbol' can not be used when making a 
shared object; recompile with -fPIC 
/usr/lib64/libboost_python.a: could not read symbols: Bad value 
collect2: ld returned 1 exit status 
 
The -fPIC option should be enabled for *all* objects going into *all* 
static libraries distributed in FC3, in order to enable users to 
include those libraries into other static libraries (as opposed to 
including them into executables only). 
 
Jason, you patch fixes only libboost_python.a. there are other static 
libraries in boost-devel: 
 
/usr/lib64/libboost_date_time.a 
/usr/lib64/libboost_filesystem.a 
/usr/lib64/libboost_prg_exec_monitor.a 
/usr/lib64/libboost_python.a 
/usr/lib64/libboost_regex.a 
/usr/lib64/libboost_signals.a 
/usr/lib64/libboost_test_exec_monitor.a 
/usr/lib64/libboost_unit_test_framework.a 
 
So I suggest a more radical patch, directed at RPM options in general.
Please let me know if ther is anything wrong with it.

cheers,

Philippe
Comment 3 Philippe Rigault 2004-11-14 20:48:23 EST
Oops, important typo: s/static/shared/g 
 
-fPIC affects SHARED libraries. 
 
The paragraph should read: 
 
The -fPIC option should be enabled for *all* objects going into *all*  
shared libraries distributed in FC3, in order to enable users to  
include those libraries into other shared libraries (as opposed to  
including them into executables only).  
 
 
Comment 4 Benjamin Kosnik 2004-11-29 19:33:34 EST
These patches are incorrect. This should be fixed in gcc-tools.jam. 

I'm updating to boost-1.32.0, please try those rpms.

-benjamin
Comment 5 Benjamin Kosnik 2004-11-30 12:34:03 EST
Here's an updated package for boost-1.32.0. 

http://people.redhat.com/bkoz/boost-1.32.0/

I believe it resolves this problem. Can you confirm?

-benjamin
Comment 6 Benjamin Kosnik 2004-12-02 11:22:34 EST
Fixed in 1.32.0-1.

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