corsepiu at faw.uni-ulm.de
Mon Apr 28 16:03:27 UTC 2003
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-18.104.22.168 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
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
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
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
# find . -name 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
your application will be linked with lib/mpentium/libc.a.
> > > 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
Building gcc/newlib multilib'ed and RTEMS multilib'ed also should be
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
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).
More information about the users