Re: libiberty...

[Philip Blundell <Philip dot Blundell at pobox dot com>]

>When I build libiberty on x86 or ARM Linux it builds .o files without
>-fpic in libiberty, and -o files with -fpic in libiberty/pic.  It builds
>libiberty.a using the .o files in libiberty, but makes no use of the .o
>files in libiberty/pic.  Should it build a shared library as well?

That might be dangerous.  Packages like gcc and gdb include variant 
libiberties of their own; there could be all sorts of nasty surprises in store 
if the version in use changes underneath you.

>I ask, because, when we build Mozilla on a NetWinder, it fails to run
>because one of the shared libraries links with -liberty.  Since the code
>it links against is in libiberty.a (compiled without -fpic) the shared
>library won't load.  The dynamic linker cannot handle the R_ARM_PC24
>relocs in the library.

I don't have any clear idea about how to deal with this.  I think that what 
Mozilla is doing here is somewhat dubious, but I don't really have any 
suggestions for how to achieve the same ends in a better way.  Also,
not supporting PC24 relocs is a deficiency in the dynamic linker and one
could say we should just bite the bullet and fix it.

>include some functionality that appears in GLIBC 2.1.2.  Offhand,
>strerror.o, getopt.o, obstack*.o pop into mind.  Should these be
>included in libiberty if on a system using GLIBC 2.1.x?  Perhaps they
>are different?

It probably isn't worth the effort to stop them from being included, to be 
honest.  At least in the past and in theory, these modules were built from a 
common set of master sources that were shared between all GNU programs.  
Whether that still holds I'm not quite sure.

p.