Configure flags no longer working.

[Ralf Corsepius]

Am Mit, 2003-04-30 um 08.59 schrieb 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.
The basic feature, code under cpukit must fullfil is to be
BSP-independent.

Or to put it differently: cpukit provides the "BSP-independent
RTEMS-kernel-library" while all other code (except of the c/src/tests/)
provides 
* BSP-dependent modules to be added to the "RTEMS-kernel"
* BSP-dependent configuration.

> > 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.
The ppc supports multilibs.

Unfortunately, the ppc wrt. some aspects of multilibs for the ppc is
dreadful.

> > Can the multilib stuff let me do that?
What you describe probably is very similar to what Chris does. multilibs
do not solve all problems wrt. this, but they assist you.

>   If so how?
Build and _install_ RTEMS multilib'ed, basically this means:

<path>/configure --enable-multilib --prefix=<whatever> \
--target=<your-target>
make RTEMS_BSP=
make RTMES_BSP= install

Afterwards the cpukit will be installed, and you can write your BSP by
whatever means, following whatever design principles you want.
 
Ralf