can't handle reloc type 0x15 in lib

[Brent Cook]

On Monday 16 January 2006 14:42, Brent Cook wrote:
> On Monday 16 January 2006 13:58, Brent Cook wrote:
> > dlopen("/usr/lib/python2.4/site-packages/userstack/_userstack.so", 2);
> >
> > python: symbol 'rand_open': can't handle reloc type 0x15 in lib
> > '/usr/lib/libuserstack.so.1'
> > Segmentation fault
>
> FYI, this on PPC with GCC 4.0.2. The relocation type is 'R_PPC_GOT16_LO',
> which is not  handled in ldso/powerpc/elfinterp.c's _dl_do_reloc function.
>
> How do I compile my code to not use this relocation type, or if not
> possible, how do I implement handling for this?
>
> Thanks,
>  - Brent
> _______________________________________________

I fixed this yesterday; it was not an issue with -fPIC. When I was building 
the library 'libuserstack' which depends on 'libdnet' and 'libnet', I did not 
include -lnet and -ldnet when linking (is that the right term?) the shared 
library. Naturally, when a program tries to dlopen a library that is not 
explicitly linked to its dependencies, I would expect an error. But, this 
also applies to dlopening a 3rd library that _is_ linked to all of the 
dependencies, but whose dependencies are not necessarily linked properly. 
Linking order of the 3rd library does not make a difference.

This does not appear to affect glibc; I can build and use the libuserstack 
library without any extra linker flags as long as I include -lnet and -ldnet 
with any derivative library or executable (e.g. the SWIG python wrapper). 
With uClibc, the explicit link with the first shared library is required to 
avoid a GOT16_LO relocation type.

Here is a generic summary of the behavior:

Lib A depends on symbols from lib B, but is not explicitly linked to lib B
Lib C depends on symbols from lib A and B, and is linked -lA -lB
Binary X is linked -lA -lB, works fine
Binary Y dlopen's lib C, fails due to missing references in lib A to lib B

Linking lib A with -lB fixes the problem.