linux-mips-fnet
[Top] [All Lists]

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

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Mips/Linux integration of latest GCC, Binutils & GLibc
From: Tim Wilkinson <tim@transvirtual.com>
Date: Wed, 08 Mar 2000 20:55:17 +0000
Cc: linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@engr.sgi.com
Organization: Transvirtual Technologies, Inc.
References: <38C54F05.458A3EFE@transvirtual.com> <20000308140301.B1425@uni-koblenz.de> <38C6A5D4.F08DFCE4@transvirtual.com> <20000308174251.A6399@uni-koblenz.de>
Sender: tim@www.transvirtual.com
Ralf,

Okay this makes sense.  This then means there's a problem with GLIBC since it
excludes certain files when building a static library but unfortuantely needs 
them
because it uses #ifdef PIC to include bits of code related to shared library
workings (essentially it considers PIC to mean SHARED when this may not infact 
be
the case - not for MIPS anyway).

So what you're saying is pretty much how I have my gcc, binutils and glibc set 
up
- I introduced a -DSHARED to glibc (which I suspect isn't really okay) when
building shared libraries so static libraries didn't include the bad code.  I 
may
look for a better solution however.

I've also made a bunch of elf related changes to mips/linux so that the 
assembler
output from gcc is more like the elf output for the x86/linux targets.  It's
interesting to note that mips/linux doesn't even defined linux for CPP (and
doesn't do a bunch of other stuff either come to that) which confused things no
end when compiling the linux kernel.

Cheers
Tim

> 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

--
  Tim Wilkinson                         Tel:     (510) 527-4025 ext 12
  Transvirtual Technologies, Inc.,      Fax:     (510) 559-3287
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com



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