Conflict when modifying newlib/openrisc to work for RTEMS

[Hesham Moustafa]

On Wed, Mar 19, 2014 at 8:00 AM, Hesham Moustafa
<heshamelmatary at gmail.com>wrote:

>
>
>
> On Wed, Mar 19, 2014 at 3:33 AM, Hesham Moustafa <heshamelmatary at gmail.com
> > wrote:
>
>>
>>
>>
>> On Tue, Mar 18, 2014 at 8:26 PM, Joel Sherrill <joel.sherrill at oarcorp.com
>> > wrote:
>>
>>>
>>> On 3/18/2014 1:07 PM, Hesham Moustafa wrote:
>>>
>>> Hi,
>>>
>>>  I am working on modifying or1k newlib port to be built for RTEMS.
>>> Building and installing
>>> newlib with --target=or1k-elf is done successfully, however, when I try
>>> to build newlib
>>> with --target=or1k-rtems4.11 I got conflict error.
>>>
>>>  part of this error is
>>> "sys/rtems/crt0.c:72:22: error: conflicting types for 'read'"
>>>
>>>   Hmmm... how old is there newlib?
>>>
>>> I think their toolchain depends on newlib-2.0.0, but I have generated
>> patches
>>  to work with newlib-2.1.0.
>>
>>>  What's the prototype for read() versus unistd.h (or whereever it turns
>>> out to
>>> be prototyped)?
>>>
>>> in newlib/libc/include/sys/unistd.h
>>
>> _READ_WRITE_RETURN_TYPE _EXFUN(read, (int __fd, void *__buf, size_t
>> __nbyte ));
>> _READ_WRITE_RETURN_TYPE _EXFUN(write, (int __fd, const void *__buf,
>> size_t __nbyte ));
>>
>> It seems like the problem was about ssize_t.
> I was able to work around this error by replacing return type of read from
> ssize_t to int.
> Not sure if this is the correct action to do or not, but I am not sure
> where to redefine
> ssize_t for or1k target.
>
>> and write function which conflicts too.
>>
>>>  It may also be possible that the or1k port doesn't have the underlying
>>> type
>>> definitions complete or correct.
>>>
>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html
>>>
>>> isn't the latest but read() requires ssize_t and size_t to be correctly
>>> and
>>> consistently defined for a target.
>>>
>>> You may end up having to reproduce the compile of crt0.c by hand and
>>> change the -c to a -E .. changing the output file.. and see what really
>>> is being preprocessed
>>>
>>> I did that exactly and I found out that both read and write are
>> prototyped as
>>
>> int read (int __fd, void *__buf, size_t __nbyte );
>> int write (int __fd, const void *__buf, size_t __nbyte );
>>
>> Also there is another syntax error at crt0.c
>> "../../../../../../../newlib-2.1.0-or1k/newlib/libc/sys/rtems/crt0.c:74:37:
>> error: expected ')' before '*' token
>>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>>
>> When I checked the output of -E I found out the following prototype :
>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int (*(sigset_t
>> *set) = ~(0), 0) { return -1; }
>>
>> For this error I checked the -E output file and found out that :
> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; is translated to
> >
> int (*(sigset_t *set) = ~(0), 0) { return -1; }
>
Someone had the same problem here [1] when trying to build newlib for
microblaze-rtems.
I am also using Ubuntu.

[1] http://sourceware.org/ml/newlib/2012/msg00529.html

> and
>> typedef unsigned long sigset_t;
>> is out there.
>>
>> (I did not apply newlib-sys-signal-20130532.diff patch, yet, at the RSB
>> which
>>  do nothing with this error)
>>
>>>  or1k/newlib port implements some stuff at libgloss (including
>>> or1k/crt0.S)
>>>
>>>   rtems uses nothing in libgloss.
>>>
>>>  I just use --target=or1k-xxx --prefix=xxx as configuration options for
>>> newlib.
>>>
>>>   The RTEMS builds take more. Check rtems-source-builder. Also if you
>>> are
>>> not building or1k-rtems tools including binutils and gcc+newlib together
>>> at the same time, it may be causing issues.
>>>
>> For RSB, I can only see that newlib is linked into gcc directory and then
>> gcc is built with
>> --with-newlib option (what am I missing ?)
>>
>> binutils (or1k-rtems4.11-*) is installed
>> and exported at prefix location. The process which I make is
>> 1- Build and install patched binutils-2.24 for RTEMS [successful]
>> 2- Build and install bootstrap patched gcc-4.8.2 [successful]
>> 3- Build and install patched newlib-2.1.0 [stuck here]
>> 4- Build and install patched gcc-4.8.2 with newlib
>>
>> Again, this process works fine with --target=or1k-elf and I am able to
>> compile simple
>> hello world program, it only conflicts at the previous 3rd point when
>> targeting
>> or1k-rtems4.11.
>>
>>>
>>>  Thanks,
>>> Hesham
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Developmentjoel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140319/db34be48/attachment.html>