Bug 149284 - cannot link librpcsvc.a into a shared object on x86_64
Summary: cannot link librpcsvc.a into a shared object on x86_64
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 164811
TreeView+ depends on / blocked
 
Reported: 2005-02-21 22:49 UTC by Jason Vas Dias
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-22 16:56:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jason Vas Dias 2005-02-21 22:49:01 UTC
Description of problem:

This program will compile with -fPIE and link OK with -pie
with FC4 glibc-2.3.4-10 on every architecture except x86_64:

--- BEGIN x86_rpc_test.c: 
#include <sys/types.h>
#include <unistd.h>
#include <rpc/rpc.h>
#include <rpc/pmap_prot.h>
#include <rpcsvc/rquota.h>

int main(int argc, char **argv, char **envp)
{
    struct getquota_args gq_args;
    struct getquota_rslt gq_rslt;
    struct sockaddr_in bogus_addr;
    struct timeval timeout = {0, 500};
    int socket = RPC_ANYSOCK;
    enum clnt_stat clnt_stat =
        clnt_call( clntudp_create(&bogus_addr, RQUOTAPROG, RQUOTAVERS,
timeout, &socket),
                   RQUOTAPROC_GETQUOTA,
                   (xdrproc_t) xdr_getquota_args, (char *) &gq_args,
                   (xdrproc_t) xdr_getquota_rslt, (char *) &gq_rslt,
                   timeout
                 );
    return (int)clnt_stat;
}
--- END x86_rpc_test.c 

On every architecture except x86_64, you can do:

$ gcc -fPIE -o x86_rpc_test.o -c x86_rpc_test.c
$ gcc -pie -o x86_rpc_test x86_rpc_test -lrpcsvc

In the /mnt/build/beehive/dist-fc4-build buildroot of 
'dolly.build.redhat.com', the above steps give this error:

# gcc -fPIE -o x86_rpc_test.o -c x86_rpc_test.c
# gcc -pie -o x86_rpc_test x86_rpc_test.o -lrpcsvc
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../lib64/librpcsvc.a(xrquota.o):
relocation R_X86_64_PC32 against `xdr_string@@GLIBC_2.2.5' can not be
used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

No errors occur if you do not try to make a -pie executable.

Exactly the same link error occurs if you compile x86_rpc_test.c with 
-fPIC, or -fpie, or -fpic, or without any -f options .
 

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

glibc-2.3.4-10

How reproducible:
100%

Steps to Reproduce:
Try to compile above program into a -pie executable
  
Actual results:
Link error

Expected results:
a -pie executable

Comment 1 Jakub Jelinek 2005-02-22 08:32:22 UTC
Why should be quota a PIE?
librpcsvc.a is a -fno-pic library, so can't be linked into PIEs nor shared
libraries.

Comment 2 Jason Vas Dias 2005-02-22 16:53:23 UTC
So why can librpcsvc.a be linked into -pie executables on every platform 
except x86_64 ?  
I was trying to build the netatalk package daemons with the -fPIE / -pie
execshield options, as they are network facing and have root privilege .
Now I have to remove these options only for the x86_64 platform because of
this problem .


Comment 3 Jakub Jelinek 2005-02-22 16:56:27 UTC
It wouldn't pass rpmdiff on other arches because of DT_TEXTREL.
x86-64 already requires in the linker that -fpic/-fpie/-fPIC/-fPIE objects
are used in PIEs (and only -fpic/-fPIC in DSOs).

Anyway, I have changed the librpcsvc.a build earlier today and Uli commited
it to upstream CVS.  So when new fc4 glibc rpms are built, it will be there.
But it might take a few days.

Comment 5 Jakub Jelinek 2005-07-06 17:23:40 UTC
RHEL4 U2 initial glibc testing RPMs that should address also this problem
uploaded to ftp://people.redhat.com/jakub/glibc/2.3.4-2.10/



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