relocation R_X86_64_PC32 and shared libraries

relocation R_X86_64_PC32 and shared libraries

[Matthew L Daniel]

I am running Fedora Core 3 (x86_64) with:
gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17)
(I've also tried with gcc4 (GCC) 4.0.0 20050125 (Red Hat 4.0.0-0.22))
GNU ld version 2.15.95 20050302 (cvs update as of this morning)
glibc-devel-2.3.4-2.fc3

When I try and compile Mozilla from CVS, I get the following error:

> gcc -shared -Wl,-soname -Wl,libnspr4.so -o libnspr4.so [lots of o files]
...
> /usr/bin/ld: io/./priometh.o: relocation R_X86_64_PC32 against
> `memcpy@@GLIBC_2.2.5' can not be used when making a shared object;
> recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value

It WAS compiled with "-pipe -ansi -Wall -pthread -O2 -fPIC"
and a bunch of Mozilla defines.

$ file io/./priometh.o
io/./priometh.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
$ nm io/./priometh.o | grep memcpy
                 U memcpy

Here is the exact command I ran, along with my prior plea for help. :-)

http://groups-beta.google.com/group/netscape.public.mozilla.builds/browse_thread/thread/df8c4bf5a64462c9/af3d0723d08402b1

I tried searching the binutils mailing list archive and this is the
closest I found to my issue:
http://sourceware.org/ml/binutils/2004-10/msg00293.html

  Any help would be greatly appreciated,
  -- /v\atthew

Re: relocation R_X86_64_PC32 and shared libraries

[H. J. Lu]

On Wed, Mar 02, 2005 at 11:45:23AM -0500, Matthew L Daniel wrote:
> I am running Fedora Core 3 (x86_64) with:
> gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17)
> (I've also tried with gcc4 (GCC) 4.0.0 20050125 (Red Hat 4.0.0-0.22))
> GNU ld version 2.15.95 20050302 (cvs update as of this morning)
> glibc-devel-2.3.4-2.fc3
> 
> When I try and compile Mozilla from CVS, I get the following error:
> 
> > gcc -shared -Wl,-soname -Wl,libnspr4.so -o libnspr4.so [lots of o files]
> ...
> > /usr/bin/ld: io/./priometh.o: relocation R_X86_64_PC32 against
> > `memcpy@@GLIBC_2.2.5' can not be used when making a shared object;
> > recompile with -fPIC
> > /usr/bin/ld: final link failed: Bad value
> 
> It WAS compiled with "-pipe -ansi -Wall -pthread -O2 -fPIC"
> and a bunch of Mozilla defines.
> 
> $ file io/./priometh.o
> io/./priometh.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
> $ nm io/./priometh.o | grep memcpy
>                  U memcpy
> 

I don't think it a linker problem. Send me a preprocessed priometh.cc
and compiler flags used to compile it. I will take a look.


H.J.

Re: relocation R_X86_64_PC32 and shared libraries

[Matthew L Daniel]

[I'm putting this back on the list so future generations can benefit
from this discussion; also so I can point the Mozilla folk to this
thread]

> It is a bug in source. If you count "#pragma GCC visibility", you will
> find there is one more push than pop. After you add the missing pop,
> everything should be OK. Unfortunately, gcc doesn't warn about it.

I was not aware that #pragma lines were something under my control at
the source level (even though it's not "my" code).

In short, can you advise some steps I (or the owners of nsprpub) can
take to resolve that?

  Thanks again for your help,
  -- /v\atthew

Re: relocation R_X86_64_PC32 and shared libraries

[H. J. Lu]

On Thu, Mar 03, 2005 at 11:12:35AM -0500, Matthew L Daniel wrote:
> [I'm putting this back on the list so future generations can benefit
> from this discussion; also so I can point the Mozilla folk to this
> thread]
> 
> > It is a bug in source. If you count "#pragma GCC visibility", you will
> > find there is one more push than pop. After you add the missing pop,
> > everything should be OK. Unfortunately, gcc doesn't warn about it.
> 
> I was not aware that #pragma lines were something under my control at
> the source level (even though it's not "my" code).
> 
> In short, can you advise some steps I (or the owners of nsprpub) can
> take to resolve that?

It is a gcc bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297


H.J.

Re: relocation R_X86_64_PC32 and shared libraries

[Matthew L Daniel]

Thanks a million for you help with this. Removing the offending pragma
tests from nsprpub and the top configure script made it build great.

  -- /v\atthew