Bug 158623 - libipq not build with -fPIC
libipq not build with -fPIC
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: iptables (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-24 06:47 EDT by Panu Matilainen
Modified: 2010-04-27 22:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 16:04:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Panu Matilainen 2005-05-24 06:47:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Firefox/1.0.2 Red Hat/1.0.2-1.4.1

Description of problem:
Trying to build software using libpq on x86_64 fails with this:

gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m64 -D_GNU_SOURCE -fPIC -fPIC -I/usr/include/libipq -I/usr/include/python2.3 -c ipqueue.c -o build/temp.linux-x86_64-2.3/ipqueue.o
creating build/lib.linux-x86_64-2.3
gcc -pthread -shared build/temp.linux-x86_64-2.3/ipqueue.o -lipq -o build/lib.linux-x86_64-2.3/ipqueue.so
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../lib64/libipq.a(libipq.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../lib64/libipq.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
error: Bad exit status from /var/tmp/rpm-tmp.21745 (%build)


Version-Release number of selected component (if applicable):
iptables-1.2.11-3.1.RHEL4

How reproducible:
Always

Steps to Reproduce:
1. Download http://woozle.org/~neale/src/ipqueue/ipqueue-1.2.tar.gz
2. Run "python setup.py build" 

  

Actual Results:  See description

Expected Results:  It should link correctly

Additional info:

Truly trivial to fix, just add -fPIC to OPT in iptables.spec:
--- iptables.spec.rh    2005-05-24 13:46:41.000000000 +0300
+++ iptables.spec       2005-05-24 13:35:29.000000000 +0300
@@ -82,7 +82,7 @@

 %build
 TOPDIR=`pwd`
-OPT="$RPM_OPT_FLAGS -I$TOPDIR/include"
+OPT="$RPM_OPT_FLAGS -I$TOPDIR/include -fPIC"
 make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib}
 make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib} iptables-save iptables-restore
 make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib} ip6tables-save ip6tables-restore

With iptables built like this the python-ipqueue thing builds correctly.
Comment 1 Norman Elton 2006-08-14 16:45:23 EDT
Is this going to be fixed in a future release? Are there any work arounds to this? 

I'm experiencing the same problem.

Thanks
Comment 2 Norman Elton 2006-08-16 08:17:44 EDT
I have rebuilt iptables, as suggested by Panu. It appears to help.

It would be very good to include this in a future release.

Thanks

Norman
Comment 3 RHEL Product and Program Management 2006-09-05 15:52:14 EDT
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.
Comment 4 RHEL Product and Program Management 2006-09-05 16:04:17 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 5 John Morris 2010-04-27 22:59:05 EDT
This is appalling.  I was about to file this bug myself since an initial search didn't turn anything up after I rediscovered the fix.  Then I remembered the default search doesn't include CLOSED bugs and sure enough... Bah, thats a day shot to heck on a bug you guys have known the solution to for a few days short of five years!

This is certainly a bug.  CPAN packages like IPTables::IPv4::DBTarpit::Tools build on x86 systems and fail on x86_64 without this fix.

As for "The component this request has been filed against is not planned for inclusion in the next update." that is bogus.  iptables-devel isn't going anywhere or there would be howls of outrage.  It is in RHEL5 and current Fedora so odds are it is in RHEL6 as well.  You issued an update in '08 to this very package but couldn't be bothered to add this five character patch.

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