Shared library linking problem.

Shared library linking problem.

[Rob Browning]

We recently switched to egcs here for a project which built a bunch of
shared libraries (platform is linux/libc6).  The problem is that now
we can only get our applications to run if we link in our object files
statically.  If we try to use shared libraries as we did with the
normal gcc, we get this error on launch:

  BUG IN DYNAMIC LINKER ld.so: ../sysdeps/i386/dl-machine.h: 291:
  elf_machine_rel: Assertion `! "unexpected dynamic reloc type"' failed!

Thanks in advance for any assistance.

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30

Re: Shared library linking problem.

[H.J. Lu]

> 
> 
> We recently switched to egcs here for a project which built a bunch of
> shared libraries (platform is linux/libc6).  The problem is that now
> we can only get our applications to run if we link in our object files
> statically.  If we try to use shared libraries as we did with the
> normal gcc, we get this error on launch:
> 
>   BUG IN DYNAMIC LINKER ld.so: ../sysdeps/i386/dl-machine.h: 291:
>   elf_machine_rel: Assertion `! "unexpected dynamic reloc type"' failed!
> 

I heard this once with Qt. Which glibc 2 are you using? I have
no problem with the slightly older glibc 2.1 on x86 and glibc
2.0.5c on alpha.

If you can send me a test case, I will look into it.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: Shared library linking problem.

[Marc Lehmann]

>
>I heard this once with Qt. Which glibc 2 are you using? I have
>no problem with the slightly older glibc 2.1 on x86 and glibc
>2.0.5c on alpha.

I had this with qt, too, but now I have this with qt, kde, and many other
shared libs..

The reason is a R_386_PLT32 relocation record in the shared library, which
is caused by a PLT reference (like _._Array@PLT) in the code (maybe
it wasn'T resolved on linking or whatever).

I've tracked it down, but I have no idea why this is happening..
maybe you can enlighten me? In any case, this is very disgusting,
since you have no chance of finding out which entry caused
the bug, unless you heavily modify ld.so

glibc-2.0.5c on x86, btw..

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

Re: Shared library linking problem.

[H.J. Lu]

> 
> >
> >I heard this once with Qt. Which glibc 2 are you using? I have
> >no problem with the slightly older glibc 2.1 on x86 and glibc
> >2.0.5c on alpha.
> 
> I had this with qt, too, but now I have this with qt, kde, and many other
> shared libs..
> 
> The reason is a R_386_PLT32 relocation record in the shared library, which
> is caused by a PLT reference (like _._Array@PLT) in the code (maybe
> it wasn'T resolved on linking or whatever).
> 

Can you tell me how I can reproduce it?


H.J.

Re: Shared library linking problem.

[Rob Browning]

hjl@lucon.org (H.J. Lu) writes:

> I heard this once with Qt. Which glibc 2 are you using? I have
> no problem with the slightly older glibc 2.1 on x86 and glibc
> 2.0.5c on alpha.

Apologies all around, the problem's solved.  It turned out someone
here had accidentally deleted -fPIC in a dark corner of our bloated
Makefile.

Sorry for the false alarm.

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30

Re: Shared library linking problem.

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> I heard this once with Qt. Which glibc 2 are you using? I have
> no problem with the slightly older glibc 2.1 on x86 and glibc
> 2.0.5c on alpha.

I guess it's a binutils problem.  The last report showed an illegal
the in the section table.

Try to use 'readelf' or 'elfdump' to see what's the content of the
ELF headers.

-- Uli
---------------.      drepper at gnu.org  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Shared library linking problem.

[Neal Becker]

This is the same problem I reported a couple of days ago!  Readelf
showed an illegal relocation.  (I'm not at my linux machine right now, 
so I can't give details).

Re: Shared library linking problem.

[Neal Becker]

I just encountered the same problem.  I used egcs-971023,
binutils-2.8.1.0.1, glibc-2.0.5, qt-1.31, linux-586.

Re: Shared library linking problem.

[H.J. Lu]

> 
> I just encountered the same problem.  I used egcs-971023,
> binutils-2.8.1.0.1, glibc-2.0.5, qt-1.31, linux-586.
> 

I have got qt-1.31. I need to know exactly how to reproduce the
bug.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: Shared library linking problem.

[Neal Becker]

All I did was build qt-1.31 out of the box.  I believe all I did was
say
make linux-gcc-shared.

In Makefile (qt-1.31 top level):
CFLAGS=-O2 -Wall -W -I/usr/X11R6/include
LIBCFLAGS=-fPIC

Those are perhaps the only things I edited in the qt-1.31 dir.

I used egcs-971023, binutils-2.8.1.0.1, glibc-2.0.5 on linux-i586.

Re: Shared library linking problem.

[H.J. Lu]

> 
> All I did was build qt-1.31 out of the box.  I believe all I did was
> say
> make linux-gcc-shared.
> 
> In Makefile (qt-1.31 top level):
> CFLAGS=-O2 -Wall -W -I/usr/X11R6/include
> LIBCFLAGS=-fPIC
> 
> Those are perhaps the only things I edited in the qt-1.31 dir.
> 
> I used egcs-971023, binutils-2.8.1.0.1, glibc-2.0.5 on linux-i586.
> 

I have no problem with qt 1.31 on linux/glibc 2.0.5c, linux/glibc 2.1
and linux/libc 5. I am using egcs-971023 and binutils 2.8.1.0.15.
I need more info to verify the bug. Please first try binutils
2.8.1.0.15.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)