build RTEMS TIc4x

[Joel Sherrill]

Ralf Corsepius wrote:
> On Thu, 2006-11-09 at 15:54 +0800, liu danil wrote:
>   
>>>> 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
>>>>
>>>>
>>>>         
>> I waited for two days but no one teached me how to solve such problems, so 
>> I tried to figure it out myself.
>>     
>
> RTEMS is run by volunteers, so you can't push anybody.
>
>   
>> First I upgraded automake to version 1.10 and autoconf to version 2.60.
>>
>> Then configure RTEMS. there were many warnings such like this:
>> /usr/local/share/aclocal/winsz.m4:5:   run info '(automake)Extending 
>> aclocal'
>> /usr/local/share/aclocal/winsz.m4:5:   or see 
>> http://sources.redhat.com/automake
>> /automake.html#Extending-aclocal
>>     
> You are doing something very wrong and seem to have screwed up your
> toolchain. winsz.m4 is not part of any standard auto* package, so you
> probably are seeing followup errors of something else.
>
> But, you are giving too little details to be able to help you.
>
>   
>> I neglected them, and went on to the make step.
>> While made RTEMS, There were several errors, I figured them out:
>>
>> 1.  force typedef uint16_t, uint8_t to uint32_t and typedef int16_t, int8_t 
>> to int32_t
>>     
> int<N>_t are standardized by POSIX. The tic4x is not POSIX compliant and
> does not have these types, so defining them is an error - period.
>
> If you really want to apply a brute-force hack, substitute all
> occurrences of int16_t and int8_t by int_least16_t rsp int_least8_t in
> RTEMS code.
>
>   

This must be what I was remembering as the problem that prevented it 
from being buildable.
>> /opt/rtems/tic4x-rtems/c3xsim/lib/librtemscpu.a(libscore_a-threadhandler.o):threadhandler.:(.text+0x27): 
>> undefined reference to `__init'
>> /opt/rtems/tic4x-rtems/c3xsim/lib/librtemsbsp.a(startup.rel):bootcard.c:(.const+0x23): 
>> undefined reference to `__fini'
>>
>> How can I do to solve these problems?
>>     
> You don't seem to have the rtems-patches to newlib and gcc applied.
>
>   
That explains the __init/__fini problem but the console one may indicate 
a missing file in the Makefile.am
or something worse.

> I am inclined to take out the tic4x from the rtems-4.7 supported
> targets.
>
>   

I thought we already had.

> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>