4.6.0pre3 available

[gregory.menke at gsfc.nasa.gov]

Ralf Corsepius writes:
 > Am Mon, 2003-04-28 um 18.33 schrieb gregory.menke at gsfc.nasa.gov:
 > > Ralf Corsepius writes:
 > > 
 > >  > 
 > >  > >   Whenever I've been building gcc (for powerpc or
 > >  > > mips) and have forgotten to disable it, I usually end up  with gcc
 > >  > > build problems.
 > >  > I don't know what you are doing, but all rtems-gcc's on ftp.rtems.com
 > >  > have been built with multilibs enabled.
 > >  > 
 > > 
 > > I may not know either..  But, we cm everything & support multiple
 > > build platforms, so we have our own gcc & rtems build scripts.
 > OK, this might explain your problems ...
 > 
 > > Is --enable-multilib supposed to be used on gcc and rtems, or just one
 > > or the other?
 > Well, it depends on many details. 
 > 
 > Somewhat oversimplifying: they need to fit.
 > 
 > Building gcc/newlib multilib'ed and RTEMS non-multilib'ed should be
 > safe.
 > Building gcc/newlib multilib'ed and RTEMS multilib'ed also should be
 > safe.
 > 
 > Building gcc/newlib non-multilib'ed means supporting one, default
 > cpu-variant for newlib only. If this default cpu-variant fits into your
 > particular target's demands building, there basically is nothing wrong
 > with it. 
 > Building RTEMS multilib'ed in this case will not work, because gcc then
 > will not support multilibs.
 > 
 > => Though it significantly increased built-times, I highly recommend
 > using a multilib'ed gcc/newlib. 
 > Building RTEMS multilib'ed however basically only is useful if using
 > serveral cpu-variants/sub-targets, or if tracking bugs and suspecting
 > gcc to be generating invalid code (eg. by compliling for i386 while
 > actually using a Pentium), or if using external BSPs (Like Chris does).
 > 

I guess the multilib issue applies for powerpc as well.  I'll give it
a try.  Thanks for your help- at least I know more about what I don't
understand.

Gregm