Re: libiberty...

[Scott Bambrough <scottb at netwinder dot org>]

Ian,

Thanks so much for the information.  I appreciate it.

> Firstly, that is a bug in the dynamic linker.

No.  I'm afraid I disagree.  If anything it is a bug in the linker.  

The PC24 reloc is a reloc for the ARM b/bl instructions.  In the normal
course of building an executable this would be resolved and never appear
in the final binary image.  In the case of a shared library, it is
copied to the final image, to be fixed up at runtime because we don't
know the absolute address to jump to (the load address is undetermined
at link time).

The dynamic linker cannot fix this up.  To do so it would have to write
to the code segment, which is read only.  If the code was compiled with
-fpic, the reloc generated would have been a PLT32 reloc.  Then the
linker would have allocated a GOT entry, and a PLT entry for the
symbol.  Since it wasn't no PLT and GOT entries are available for the
dynamic linker to use.

I've been thinking about this for a while now as it is one of the worst
support headaches I have.  I recently sent a message to Nick Clifton and
Phil Blundell about this very topic.  The linker should either convert
the reloc to a PLT32 reloc, and continue on, or it should halt with a
fatal error.  At present it doesn't even generate a warning.

Quite frankly, I wish the linker would fix up the reloc quietly and just
do the right thing.  I am concerned however that there may be othe r
relocs, particularly data relocs that need to be turned into some other
type for inclusion in the shared library.  I may be needlessly concerned
here, but I would rather be safe than sorry.

The next best thing is for the linker to generate an error, for which
Nick has kindly supplied me a patch to try.  Thanks Nick.  If you have
some other slant on the problem I'd love to hear it.

> Secondly, it is nevertheless better to include PIC code in a shared
> library.  However, we don't normally build a PIC version of libiberty.
> So I don't have a suggestion beyond changing the Mozilla build
> somehow.

Neither do I ATM :(.  Unfortunately, it is not just Mozilla that suffers
from this problem.  Orbit and libpcap come to mind as packages having
similar problems.

> getopt and obstack should compile into nothing on a system using
> glibc.  strerror will compile into only functions which glibc doesn't
> have, such as strerrno and strtoerrno.

Your right.  I should have gone and looked myself before bothering you. 
Sorry.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org