Problems when building gcc 3.2or 3.3 as cross compiler for powerpc-linux

[Richard Sewards]

Hi Nick,

I have an apparently working gcc for powerpc linux now. I was able to
create it using the kluge many stage partial builds, but fixing
config/rs6000/linux.h has also worked and allows the use of your 3 stage
build.

I also had to force inhibitlibc (by modifying the gcc/configure script)
to be set for both the minimal gcc and the full gcc using glibc.
(Actually, inhibitlibc is set if you configure gcc with --with-newlib,
which works for the minimal gcc.  For the full gcc this conflicts with
glibc and there is no other way to get -Dinhibitlibc to be set.) 

I have attached a patch showing what I changed.  It seems that when the
threading model is set to posix (the default for linux) the threading
headers include signal.h and other files from glibc and these conflict
with linux/signal.h and asm/ucontext.h which work when the threading
model is single (as used for a minimal gcc).

Regards,

--
Richard Sewards

-----Original Message-----
From: Nick Patavalis [mailto:npat@inaccessnetworks.com] 
Sent: Tuesday, May 27, 2003 1:00 PM
To: gcc-help@gcc.gnu.org
Subject: Re: Problems when building gcc 3.2or 3.3 as cross compiler for
powerpc-linux

On Tue, May 27, 2003 at 11:36:49AM -0400, Richard Sewards wrote:
> 
> I think I have found a solution by adding more steps:  I install the
> partially built minimal gcc (without libgcc.a) and use this to build
> glibc.  This fails because it cannot create the shared objects (it
needs
> libgcc.a).  However, if I do "make -k ; make -k install" I get an
> installed set of header files.  I then combine these with the kernel
> headers and use this new header collection (using --with-headers=...)
to
> reconfigure the minimal gcc, which now builds successfully. 
>

Might be usefull, as a last resort, but, you must agree, it's too
much of a kluge!
 
> I might try modifying gcc's config/rs6000/linux.h such that it doesn't
> need the glibc headers as an alternate solution (probably a better
one,
> in fact).  It should include "linux/signal.h" and "asm/ucontext.h"
> instead of "signal.h" and "sys/ucontext.h", but there may be other
> structures used too.

If you try this, please drop a line to let me know if it works

/npat

-- 
flowchart, v.: To obfuscate (a problem) with esoteric cartoons.
  -- Stan Kelly-Bootle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1
Type: application/octet-stream
Size: 1139 bytes
Desc: patch1
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20030602/856a0034/attachment.obj>