public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* R_PPC_REL24 relocation [...] __libc_start_main/__nptl_deallocate_tsd out of range
@ 2011-02-16 10:32 Stefano Bonifazi
  2011-02-16 18:29 ` kevin diggs
  0 siblings, 1 reply; 3+ messages in thread
From: Stefano Bonifazi @ 2011-02-16 10:32 UTC (permalink / raw)
  To: gcc-help

Hi!
I am working on a project using powerpc binaries I create myself.
I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc 
running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc 2.11.2-10
My binaries are someway special being compiled with -fPIC and linked 
with -pie (gcc -Wl,-pie) as I need full relocatable PIC executables.
These binaries are in fact loaded by qemu-user in different addresses.
My project (open source, as it is a university project) works fine when 
I do not use libgcc (using gcc -nostartfiles) for creating my powerpc 
executable, but it is impossible to build useful binaries without using it.
When I compile without "-nostartfiles", having libgcc added to my binary 
I get the following error at runtime:
Hi!
  Sorry I am not very sure if this is the right mailing list for posting 
my problem, I've got the address from an old thread about the same kind 
of problem.
I am working on a project using powerpc binaries I create myself.
I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc 
running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc 2.11.2-10
My binaries are someway special being compiled with -fPIC and linked 
with -pie (gcc -Wl,-pie) as I need full relocatable PIC executables.
These binaries are in fact loaded by qemu-user in different addresses.
My project (open source, as it is a university project) works fine when 
I do not use libgcc (using gcc -nostartfiles) for creating my powerpc 
executable, but it is impossible to build useful binaries without using it.
When I compile without "-nostartfiles", having libgcc added to my binary 
I get the following error at runtime:

 > R_PPC_REL24 relocation [...] __libc_start_main' out of range


I tried to link my binaries as static but I get the following:


 >   R_PPC_REL24 relocation at ... for symbol __nptl_deallocate_tsd out 
of range

(I do not use threads though!)

In some old thread I read it is related to non PIC code being linked 
together with PIC code. But the code producing the problem seems libgcc.

Is there a way for fixing this problem? Is there anybody able of explain 
fine what happens?
I have got a very strict deadline, but I can't understand fine what the 
problem is, I keep trying to install different debian versions hoping 
they would fix it..
Thank you very much in advance!
Stefano B.
 > R_PPC_REL24 relocation [...] __libc_start_main' out of range


I tried to link my binaries as static but I get the following:


 >   R_PPC_REL24 relocation at ... for symbol __nptl_deallocate_tsd out 
of range

In some old thread I read it is related to non PIC code being linked 
together with PIC code. But the code producing the problem seems libgcc.

Is there a way for fixing this problem? Is there anybody able of explain 
fine what happens?
I have got a very strict deadline, but I can't understand fine what the 
problem is for doing any step forward, I keep trying to install 
different debian versions hoping they would fix it..
Thank you very much in advance!
Stefano B.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: R_PPC_REL24 relocation [...] __libc_start_main/__nptl_deallocate_tsd out of range
  2011-02-16 10:32 R_PPC_REL24 relocation [...] __libc_start_main/__nptl_deallocate_tsd out of range Stefano Bonifazi
@ 2011-02-16 18:29 ` kevin diggs
  2011-02-21 14:42   ` Stefano Bonifazi
  0 siblings, 1 reply; 3+ messages in thread
From: kevin diggs @ 2011-02-16 18:29 UTC (permalink / raw)
  To: Stefano Bonifazi; +Cc: gcc-help

Hi,

I think I have seen this when I was resolving a symbol from a shared
library using a definition in a static library. I think I bumped into
this while trying to get a 4.1.2 rpm to build 32/64 bit multi-lib
compiler correctly. I had problems getting some of the internal
libraries correct. Either they ended up in the wrong location or what
was supposed to be a 32 bit library was a 64 bit. This caused the
linker to fail to use the shared library. It then fell back on the
static. Resulting in the dreaded relocation error.

Try linking with -v to double check what you are linking in. Also
might try ldd on the executable.

kevin

On 2/16/11, Stefano Bonifazi <stefboombastic@gmail.com> wrote:
> Hi!
> I am working on a project using powerpc binaries I create myself.
> I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc
> running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc 2.11.2-10
> My binaries are someway special being compiled with -fPIC and linked
> with -pie (gcc -Wl,-pie) as I need full relocatable PIC executables.
> These binaries are in fact loaded by qemu-user in different addresses.
> My project (open source, as it is a university project) works fine when
> I do not use libgcc (using gcc -nostartfiles) for creating my powerpc
> executable, but it is impossible to build useful binaries without using it.
> When I compile without "-nostartfiles", having libgcc added to my binary
> I get the following error at runtime:
> Hi!
>   Sorry I am not very sure if this is the right mailing list for posting
> my problem, I've got the address from an old thread about the same kind
> of problem.
> I am working on a project using powerpc binaries I create myself.
> I am creating the binaries using Debian 6 kernel 2.6.32.5 powerpc
> running in a qemu VM, with gcc 4.4.5-8, binutils 2.20.1 eglibc 2.11.2-10
> My binaries are someway special being compiled with -fPIC and linked
> with -pie (gcc -Wl,-pie) as I need full relocatable PIC executables.
> These binaries are in fact loaded by qemu-user in different addresses.
> My project (open source, as it is a university project) works fine when
> I do not use libgcc (using gcc -nostartfiles) for creating my powerpc
> executable, but it is impossible to build useful binaries without using it.
> When I compile without "-nostartfiles", having libgcc added to my binary
> I get the following error at runtime:
>
>  > R_PPC_REL24 relocation [...] __libc_start_main' out of range
>
>
> I tried to link my binaries as static but I get the following:
>
>
>  >   R_PPC_REL24 relocation at ... for symbol __nptl_deallocate_tsd out
> of range
>
> (I do not use threads though!)
>
> In some old thread I read it is related to non PIC code being linked
> together with PIC code. But the code producing the problem seems libgcc.
>
> Is there a way for fixing this problem? Is there anybody able of explain
> fine what happens?
> I have got a very strict deadline, but I can't understand fine what the
> problem is, I keep trying to install different debian versions hoping
> they would fix it..
> Thank you very much in advance!
> Stefano B.
>  > R_PPC_REL24 relocation [...] __libc_start_main' out of range
>
>
> I tried to link my binaries as static but I get the following:
>
>
>  >   R_PPC_REL24 relocation at ... for symbol __nptl_deallocate_tsd out
> of range
>
> In some old thread I read it is related to non PIC code being linked
> together with PIC code. But the code producing the problem seems libgcc.
>
> Is there a way for fixing this problem? Is there anybody able of explain
> fine what happens?
> I have got a very strict deadline, but I can't understand fine what the
> problem is for doing any step forward, I keep trying to install
> different debian versions hoping they would fix it..
> Thank you very much in advance!
> Stefano B.
>
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: R_PPC_REL24 relocation [...] __libc_start_main/__nptl_deallocate_tsd out of range
  2011-02-16 18:29 ` kevin diggs
@ 2011-02-21 14:42   ` Stefano Bonifazi
  0 siblings, 0 replies; 3+ messages in thread
From: Stefano Bonifazi @ 2011-02-21 14:42 UTC (permalink / raw)
  To: kevin diggs; +Cc: gcc-help

Hi Thank you for your reply!

I am actually trying with the simplest possible code:
int main() {}
And I always get the same problem.
I compile with -fPIC and link with -WL,-pie

I report the output after adding -v

Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.4 --enable-shared --enable-multiarch 
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib 
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --enable-secureplt --disable-softfloat 
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 
--with-long-double-128 --enable-checking=release 
--build=powerpc-linux-gnu --host=powerpc-linux-gnu 
--target=powerpc-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COMPILER_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'bin/ppc-test'
  /usr/lib/gcc/powerpc-linux-gnu/4.4.5/collect2 --build-id 
--eh-frame-hdr -V -Qy -m elf32ppclinux --hash-style=both -dynamic-linker 
/lib/ld.so.1 -o bin/ppc-test 
/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../lib/crt1.o 
/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../lib/crti.o 
/usr/lib/gcc/powerpc-linux-gnu/4.4.5/crtbegin.o 
-L/usr/lib/gcc/powerpc-linux-gnu/4.4.5 
-L/usr/lib/gcc/powerpc-linux-gnu/4.4.5 
-L/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../lib -L/lib/../lib 
-L/usr/lib/../lib -L/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../.. 
-verbose -pie runners/obj/testppc.o -lgcc --as-needed -lgcc_s 
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/powerpc-linux-gnu/4.4.5/crtend.o 
/usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../lib/crtn.o

Checking all the linked object files with "readelf -d myobjectfile | 
fgrep TEXT" all seem to be PIC as nothing is produced by the previous 
comand.
Oddly giving the command "readelf -d mypie_executable | fgrep TEXT" to 
my final 'PIC' output executable i get: "0x00000016 (TEXTREL) 0x0"
Then if I try to load the file with QEMU-USER i get: "error while 
loading shared libraries: R_PPC_REL24 relocation at 0xb31f95a0 for 
symbol `__libc_start_main' out of range" !!!

I am afraid the linker goes crazy as I want a PIC executable, not a 
shared library.. if I create a shared library (-shared) there is not 
that relocation problem!

I really dunno what to do.. where the problem comes from..
Thank you very much in advance!
Stefano B.

On 02/16/2011 07:02 PM, kevin diggs wrote:
> Hi,
>
> I think I have seen this when I was resolving a symbol from a shared
> library using a definition in a static library. I think I bumped into
> this while trying to get a 4.1.2 rpm to build 32/64 bit multi-lib
> compiler correctly. I had problems getting some of the internal
> libraries correct. Either they ended up in the wrong location or what
> was supposed to be a 32 bit library was a 64 bit. This caused the
> linker to fail to use the shared library. It then fell back on the
> static. Resulting in the dreaded relocation error.
>
> Try linking with -v to double check what you are linking in. Also
> might try ldd on the executable.
>
> kevin
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-02-21 14:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-16 10:32 R_PPC_REL24 relocation [...] __libc_start_main/__nptl_deallocate_tsd out of range Stefano Bonifazi
2011-02-16 18:29 ` kevin diggs
2011-02-21 14:42   ` Stefano Bonifazi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).