newbie questions

[Till Straumann]

Wulf Hofbauer wrote:

>Hi,
>
>I am trying to evaluate RTEMS for a DAQ/process control system
>using a MVME147 board. I am pretty confused by the building
>procedure.
>
>So far, I have been using an m68k-elf-gcc (3.2) and
>m68k-elf-binutils (2.13) for the MVME147 on an x86 GNU/Linux
>system, along with a homegrown port of newlib.
>
>The documentation in the RTEMS 4.5.0 tree as well as the
>beginner's guide claim that some pretty ancient and customized
>versions of gcc and binutils are required. A customized version
>of newlib also seems to be necessary just in order to build the
>RTEMS kernel itself.
>
>I'd prefer to work with the toolchain I have in place. Is it
>really necessary to have specific versions of gcc and binutils
>(if so, why)?
>
That's actually something I'd like to know myself.

>
>
>Also, the relation between RTEMS and newlib puzzles me. I'd
>expect to build a C library on top of RTEMS if needed.
>
Hmm I wouldn't expect a clean separation between the layers
but rather quite some amount of glue...

> The
>apparent mutual interdependence strikes me as somewhat bizzarre.
>
Well, AFAIK, RTEMS implements parts of the C library (e.g.
lowlevel-malloc, reentrancy, ...). Hence, you'd expect it to
certainly depend on the newlibc headers. Also, newlibc
needs probably be configured in a specific way so the build
process 'knows' about what parts of the C library have to
be provided by newlib and what is actually implemented by
RTEMS.

>
>Is there a way to build RTEMS without newlib?
>
Probably not too hard to do - newlib related stuff
is in c/src/lib/libc - AFAIK, the core stuff under c/src/exec
does not depend on libc.
But then - why would you want to do such a thing? Life without a C library
is no fun - you'd most likely have to port another one.

-- Till

>
>
>I am feeling considerable unease at the prospect of being locked
>into a highly specific toolchain version, especially as I fail to
>see a valid reason why there should be such strict requirements
>for creating statically linked, self-contained binaries for the
>target system. Eventually, the code will be converted to S-records
>anyway...
>
>Would someone be so kind as to fill me in about the various ifs and
>whys?
>
>Thanks in advance,
>
>- Wulf
>