On Tue, Apr 1, 2014 at 12:45 AM, Chris Johns <chr...@rtems.org> wrote:
> On 29/03/2014 9:10 am, Hesham Moustafa wrote:
>
>> Hi,
>>
>> A few weeks ago I was able to build gcc linked with newlib for
>> or1k-rtems* target. But, I had to
>> do some work-arounds to get it working which I think I have to discuss
>> it with you.
>>
>> First issue, is that when building gcc/newlib with --enable-threads
>> option, I got a lot of errors
>> which fade out when building with --disable-threads.
>> folks at openrisc IRC channel told me that newlib (with threads) never
>> been used.
>>
>
> We enable threads when building newlib so it looks like we need to clean
> this up.
>
>
>
>> Another issue was about some errors raised by inconsistent definition of
>> ssize_t type for
>> or1k target. Gedare mentioned that ssize_t should be defined in the or1k
>> target's source.
>> I asked about where (in or1k source) to define ssize_t and or1k people
>> told me it should
>> be defined at RTEMS. To be able to get around this issue, I had to
>> replace ssize_t at
>> crt0.c with int in the related functions prototypes.
>>
>
> The tools need to define ssize_t. RTEMS uses the machine level parameters
> provided to it by the tools and selected switches. These know the specific
> configuration being built. I suspect this is done in newlib somewhere.
>
>
>
>> For the same file (crt0.c) another compilation error is:
>> "error: expected ')' before '*' token RTEMS_STUB(int,
>> sigfillset(sigset_t *set), { return -1; })"
>> This macro is expanded to:
>> "int (*(sigset_t *set) = ~(0), 0) { return -1; }"
>> I had to comment this macro to pass this error.
>>
>>
> I am not sure about this one. I need to take a closer look at the code and
> the patch.
>
>
> Finally, some compilation errors which are related to POSIX (like
>> undeclared NAME_MAX)
>> were avoided by re-declaring these macros at the file raising such errors.
>>
>> I can provide any further details or error messages if required. Please
>> suggest solutions
>> to get rid of these error in the right way. The patch for newlib that
>> adds support for or1k and
>> RTEMS against newlib-2.1.0 is there [1]
>>
>
> In the coming days I will take a look at the patch and port and see what
> is happening.
>
> Thanks. I am waiting your feedback.
> Chris
>
>
>> [1]
>> https://github.com/heshamelmatary/or1k-rtems/
>> blob/master/patches/newlib-2.1.0-or1k-rtems.diff
>>
>> Regards,
>> Hesham
>>
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel@rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
