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.
Is this going to be fixed in a future release? Are there any work arounds to this? I'm experiencing the same problem. Thanks
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
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.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.
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.