Configure flags no longer working.

[Chris Johns]

Steven Johnson wrote:
> 
> I Don't see how this lets me set the compiler options for the RTEMS 
> Build to what I want.
 >

GCC knows what valid options it can support. All multilib is doing is running through 
this list and building libs for each valid set. The list is the bounds for gcc for a 
specific target. For a m68k-rtems target (ie --target=m68k-rtems) I get:

$ m68k-rtems-gcc -print-multi-lib
.;
m68000;@m68000
m5200;@m5200
mcpu32;@mcpu32
m68040;@m68040
m68060;@m68060
msoft-float;@msoft-float
m68040/msoft-float;@m68040 at msoft-float
m68060/msoft-float;@m68060 at msoft-float

This format is some sort of gcc speak.

> 
> Is there anything I can read about multilib in rtems?
> 

It is related to GCC and newlib. When you build gcc+newlib you end up with a number 
of C libraries matching the number of compiler variants. For example the default libc 
for a m68k-rtems target is the 68020 and has a path of :

$ m68k-rtems-gcc -print-file-name=libc.a
/opt/rtems/lib/gcc-lib/m68k-rtems/3.2.3/../../../../m68k-rtems/lib/libc.a

A Coldfire is found by adding the -m5200 option to gcc. Note the different end path:

$ m68k-rtems-gcc -m5200 -print-file-name=libc.a
/opt/rtems/lib/gcc-lib/m68k-rtems/3.2.3/../../../../m68k-rtems/lib/m5200/libc.a

Now onto floating point. In this example I look for a 68060 lib then the soft-float 
version:

$ m68k-rtems-gcc -m68060 -print-file-name=libc.a
/opt/rtems/lib/gcc-lib/m68k-rtems/3.2.3/../../../../m68k-rtems/lib/m68060/libc.a

$ m68k-rtems-gcc -m68060 -msoft-float -print-file-name=libc.a
/opt/rtems/lib/gcc-lib/m68k-rtems/3.2.3/../../../../m68k-rtems/lib/m68060/msoft-float/libc.a

All your are doing when you configure RTEMS with multilib is telling it to follow the 
same model and libc, libm etc but for the RTEMS cpukit. The whole reason the code has 
been move to under cpukit is to allow this to happen. Only code that can compile in 
this way can reside under cpukit. It has been a large effort by Ralf and Joel.

> Ideally I'd prefer not only no bsp, but no cpu stuff. I use a modified 
> mpc8xx CPU, that I have to patch into the code.  What I would really 
> prefer is just an RTEMS that doesn't have any of the stuff from libcpu 
> built, as I want this to be part of my application.

This is what you should get if everything works. I am not sure if the PPC will 
multilib. Ralf or Joel will know.

> 
> Can the multilib stuff let me do that?  If so how?
> 
> (Actually I fail to see a stark difference between a bsp and the stuff 
> in libcpu.)
> 

One issue libcpu handles is gcc's view of available CPU variants is limited to the 
type of code it needs to generate. The libcpu goes a step further and gets into the 
specifics of different processors which all may run the same instruction set.

-- 
  Chris Johns, cjohns at cybertec.com.au