4.6.0pre3 available

[Chris Johns]

Ralf Corsepius wrote:
>
> => 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 would like to add some of the reasons I am using multilib to complement Ralf's 
points. I see multilib and the cpukit changes as a positive move for RTEMS and 
welcome it.

As Ralf points out, multilib gives me all the m68k variants I use, eg 68000, 5200, 
68020, 68060+msoft, with one RTEMS compile and install. This is a configuration 
control win.

Multilib RTEMS means I can keep my BSP separate from RTEMS and replaces the bare BSP 
that I have used up to now. I am slowly getting to a point where I can release the 
Coldfire BSPs I have and add them to the contrib tree on OAR Corp's ftp site. These 
are self contained autoconf/automake packages. I have a couple of BSP's for products 
that are not released and will not be. For these I do not need to merge my BSP into 
the main RTEMS source tree to built it.

A multilib RTEMS means in time a binary package could be released for the cpukit. For 
example an RPM for Linux that installs the libs for your specific target. Sure you 
get more libs than you need but you do not need to build RTEMS and the libs will have 
been tested.

I feel it will also help with porting 3rd party packages to RTEMS. Knowing the cpukit 
headers and libs exist in a standard structure under the $prefix path is a plus.

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