linux-mips
[Top] [All Lists]

Re: Mips/Linux integration of latest GCC, Binutils & GLibc

To: Tim Wilkinson <tim@transvirtual.com>
Subject: Re: Mips/Linux integration of latest GCC, Binutils & GLibc
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 8 Mar 2000 17:42:51 -0300
Cc: linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com
In-reply-to: <38C6A5D4.F08DFCE4@transvirtual.com>
References: <38C54F05.458A3EFE@transvirtual.com> <20000308140301.B1425@uni-koblenz.de> <38C6A5D4.F08DFCE4@transvirtual.com>
Sender: owner-linuxmips@oss.sgi.com
On Wed, Mar 08, 2000 at 07:11:16PM +0000, Tim Wilkinson wrote:

> So here's my basic problem.  GCC, Binutils and GLIBC don't really agree about
> PIC nature of code.  GCC seems to default to PIC unless you say -no-pic, but
> even then doesn't remove the -KPIC flag to the assembler.  GLIBC requires the
> PIC symbol to be defined otherwise it uses non-pic assembly code which won't
> compile with the -KPIC flag to the assembler (there are also a bunch of
> linux/glibc compatiblity issues we won't get into right now).
> 
> So my questions is - should GCC by default generate non-pic code or should it
> generate PIC code by default?  If it generate PIC by default it needs to
> define PIC and __PIC__ ... but this will cause problems when building a
> static version of GLIBC (even though it's really a PIC version).
> 
> I would want to do the following - gcc by default doesn't build PIC code,
> fix the -KPIC flag to be passed only when generating PIC code, and make a
> few minor changes to GLIBC to allow all this to happen.

You cannot mix pic and non-pic code on MIPS, so it must generate PIC code
by default and that is also pass PIC / __PIC__ / -KPIC by default.  That's
what the real compilers (not the abortion in egcs-cvs) do.

That is static vs shared and pic vs. non-pic code are orthogonal issues
except that you cannot generate shared libs from non-pic code.  They
always have been except that the way things are handled on other
architectures doesn't make recognizing this fact very important.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>