newbie questions

[Aaron J. Grier]

On Mon, Oct 07, 2002 at 08:24:20PM -0400, Wulf Hofbauer wrote:

> 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)?

depending on your target it may not be necessary...  I have successfully
built RTEMS 4.5.0 and my associated application from CVS versions of
binutils / newlib / gcc for my 68331-based target.

kaben2$ m68k-rtems-gcc -v
Reading specs from /usr/local/cross/lib/gcc-lib/m68k-rtems/3.2/specs
Configured with: /projects/aaron/m68k-rtems/configure --target=m68k-rtems --prefix=/usr/local/cross --disable-gdbtk --without-x --enable-languages=c,objc --enable-tui
Thread model: single
gcc version 3.2 20020623 (experimental)

unfortunately libstdc++-v3 is still not working for m68k-rtems,

> Also, the relation between RTEMS and newlib puzzles me. I'd expect to
> build a C library on top of RTEMS if needed. The apparent mutual
> interdependence strikes me as somewhat bizzarre.

the problem is the exact API between RTEMS and libc is not set in stone
and is quite fluid...  both sides have to 

> Is there a way to build RTEMS without newlib?

sure -- it's just a "simple matter of programming"(tm)  as far as I know
nobody has done it.  especially since as previously mentioned even gcc
needs a target's libc.

> I am feeling considerable unease at the prospect of being locked into
> a highly specific toolchain version,

I have a counterexample that such "locking-in" is not necessary.

> 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.

there is no single reason; there are plethora of them which would make
an interesting paper.  the short list consists of all software
components involved in developing RTEMS; the long list would be the
graph of all data traversal between these components.

> Eventually, the code will be converted to S-records anyway...

right, but you have to produce a finished executable first.  :)

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com