Re: libiberty...

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Fri, 19 Nov 1999 13:57:49 -0500
   From: Scott Bambrough <scottb@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?

No.  It will use those files if you build a PIC libstdc++.  libstdc++
isn't part of binutils, but libiberty is part of gcc, and the code is
shared.

   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.

Firstly, that is a bug in the dynamic linker.

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.

   I also noticed the number of files in the REQUIRED_OFILES seems to
   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?

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.

Ian