build RTEMS TIc4x

[Ralf Corsepius]

On Wed, 2006-11-08 at 13:03 +0800, liu danil wrote:
> >From: Ralf Corsepius <ralf.corsepius at rtems.org>
> > > I checked configure.log, it had an error item told that there's no 
> gmp.h
> > > file.
> >Error or warning?
> >
> I don't know if it's a error or warning. The message is as below:

You are looking at the wrong end. This is an excerpt of a config.log,
which only means a check is reporting a negative result. How to
interpret this is subject to the configure script.

> today, I checkout RTEMS from 
> CVSROOT=:pserver:anoncvs at www.rtems.com:/usr1/CVS

This is the "unstable development" version of RTEMS (aka rtems-4.8).

The "release" versions are on cvs-branches:
* rtems-4-6-branch: old stable rtems-4.6.x
* rtems-4-7-branch: soon to be released next stable rtems-4.7.x

> and run bootstrap then run configure with command:
> --target=tic4x-rtems --quiet --disable-networking --disable-tests 
> --enable-posix --enable-itron --disable-cxx --enable-rtemsbsp="c3xsim" 
> --prefix=/opt/rtems
>
> while run make, these's an error message:
> 
> ../../../../cpukit/../../../c3xsim/lib/include/rtems/score/types.h:36: 
> error: sy
> ntax error before "Priority_Bit_map_control"
> ../../../../cpukit/../../../c3xsim/lib/include/rtems/score/types.h:36: 
> warning:
> type defaults to `int' in declaration of `Priority_Bit_map_control'
> ../../../../cpukit/../../../c3xsim/lib/include/rtems/score/types.h:36: 
> warning:
> data definition has no type or storage class
> 
> I realized that's because there's no unsigned16 and several other 
> typedefines for tic4x BSP.
Right, the tic4x doesn't have any of these.

>  Should I add these typedefines in the type.h 
> file ?
No. types.h using them is a bug.

>  defines all these types to uint32_t?
Well, some of them probably should be "[u|]int_least<N>_t" types on the
tic4x, while others (esp. 64bit types) should not be present in types.h
at all on all targets. The former is a bug in the tic4x port, the latter
is a general issue in RTEMS, which is being exposed by the tic4x.

But ... I am quite surprised to see these errors. These bugs had been
present for years and were supposed to be fixed (it affects the tic4x
and some other exotic targets). I also recall having built the tic4x
many times, but ... I am able to reproduce your error, so ... I am
wondering what might have happened. Last minute screw up when preparing
for rtems-4.7, something having gone wrong when OAR moved RTEMS to their
new server, a recent CVS check-in breaking something?

Ralf