4.6.0pre3 available

[Ralf Corsepius]

Am Mon, 2003-04-28 um 18.33 schrieb gregory.menke at gsfc.nasa.gov:
> Ralf Corsepius writes:
>  > Am Mon, 2003-04-28 um 17.21 schrieb gregory.menke at gsfc.nasa.gov:
>  > > Chris Johns writes:
>  > >  > Joel Sherrill wrote:
>  > >  > >  
>  > >  > > Now we can worry about what real problems need to be
>  > >  > > there. :)
>  > >  > >
>  > >  > 
>  > >  > None for me. :-)
>  > >  > 
>  > >  > I have successfully tested C & C++ (STL) apps with this release using the released 
>  > >  > gcc-3.2.3 + newlib-1.11.0 + binutils-2.13.2.1 tool set for the Coldfire processor 
>  > >  > (5206e + 5272).
>  > >  > 
>  > >  > I used the multilib option and built no BSPs (gmake RTEMS_BSP=""). The multilib 
>  > >  > option is excellent and removes my need to use the bare BSP.
>  > >  > 
>  > >  > Excellent effort.
>  > > 
>  > > Please pardon my possibly stupid question, but what is the multilib
>  > > and why is it needed?
>  > multilibs are a gcc feature to build libs multiple times using different
>  > sets of compilation flags for different sub-targets, resulting into
>  > libraries being optimized for different sub-targets.
>  > 
>  > Configuring the RTEMS source tree with --enable-multilib builds the
>  > cpukit multilib'ed, ie. one time each for each multilib-sub-target of
>  > gcc. 
> 
> What is an example of a sub-target?

OK, I seem to have been too brief. I actually meant a cpu-variant of a
particular cpu-family. 

For example, i386dx, i386+i387, i486, i586, i686, athon, duron, k6, k7
etc. are such kind of cpu-variants of RTEMS's i386-cpu-family.

<target>-rtems-gcc --print-multi-lib gives you the set of cpu-variants a
particular gcc has built in.

For the i386-cpu-family:

# i386-rtems-gcc --print-multi-lib
.;
m486;@mcpu=i486
mpentium;@mcpu=pentium
mpentiumpro;@mcpu=pentiumpro
k6;@mcpu=k6
athlon;@mcpu=athlon
soft-float;@msoft-float
soft-float/nofp;@msoft-float at mno-fp-ret-in-387
m486/soft-float;@mcpu=i486 at msoft-float

Each line denotes a cpu-variant, with right side of each line (after
the) ';' containing the set of compilation flags to be used to compile
for this cpu-variant, and the left side (before the ';') showing a
directory.

This mapping is applied when building gcc, newlib and cpukit with
--enable-multilib. This results into each library being compiled for
each of the lines above.

For example, for i386-rtems-newlib you will find these versions of
libc.a

# find . -name libc.a
./lib/athlon/libc.a
./lib/k6/libc.a
./lib/m486/soft-float/libc.a
./lib/m486/libc.a
./lib/mpentium/libc.a
./lib/mpentiumpro/libc.a
./lib/soft-float/nofp/libc.a
./lib/soft-float/libc.a
./lib/libc.a


These directories get automatically appended as directory suffixes to
the library search paths when linking.

I.e. if you are linking an i386-application using 
i386-rtems-gcc -mpentium,
your application will be linked with lib/mpentium/libc.a.
etc.

> 
> 
>  > 
>  > >   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).

Ralf