[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Mon, 14 Oct 2002 17:20:12 -0700
- From: aaron at frye.com (Aaron J. Grier)
- Subject: newbie questions
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