This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: libiberty...
- To: Scott Bambrough <scottb at netwinder dot org>
- Subject: Re: libiberty...
- From: Philip Blundell <Philip dot Blundell at pobox dot com>
- Date: Fri, 19 Nov 1999 19:48:55 +0000
- cc: binutils mailing list <binutils at sourceware dot cygnus dot com>
- References: <38359DAD.2E38F447@netwinder.org>
>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.