<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 5:04 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Wed, Mar 19, 2014 at 2:00 AM, Hesham Moustafa<br>
<div><div class="h5"><<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Mar 19, 2014 at 3:33 AM, Hesham Moustafa <<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Mar 18, 2014 at 8:26 PM, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On 3/18/2014 1:07 PM, Hesham Moustafa wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I am working on modifying or1k newlib port to be built for RTEMS.<br>
>>> Building and installing<br>
>>> newlib with --target=or1k-elf is done successfully, however, when I try<br>
>>> to build newlib<br>
>>> with --target=or1k-rtems4.11 I got conflict error.<br>
>>><br>
>>> part of this error is<br>
>>> "sys/rtems/crt0.c:72:22: error: conflicting types for 'read'"<br>
>>><br>
>>> Hmmm... how old is there newlib?<br>
>>><br>
>> I think their toolchain depends on newlib-2.0.0, but I have generated<br>
>> patches<br>
>>  to work with newlib-2.1.0.<br>
>>><br>
>>> What's the prototype for read() versus unistd.h (or whereever it turns<br>
>>> out to<br>
>>> be prototyped)?<br>
>>><br>
>> in newlib/libc/include/sys/unistd.h<br>
>><br>
>> _READ_WRITE_RETURN_TYPE _EXFUN(read, (int __fd, void *__buf, size_t<br>
>> __nbyte ));<br>
>> _READ_WRITE_RETURN_TYPE _EXFUN(write, (int __fd, const void *__buf, size_t<br>
>> __nbyte ));<br>
>><br>
> It seems like the problem was about ssize_t.<br>
> I was able to work around this error by replacing return type of read from<br>
> ssize_t to int.<br>
> Not sure if this is the correct action to do or not, but I am not sure where<br>
> to redefine<br>
> ssize_t for or1k target.<br>
</div></div>You'll need to fix the or1k target's definition of ssize_t, not hack unistd.h.<br>
<div><div class="h5"><br></div></div></blockquote><div>I did not hack unitstd.h, instead I changed the return type of read prototype at </div><div>sys/rtems/crt0.c to int instead of ssize_t. is that acceptable ?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5">
>><br>
>> and write function which conflicts too.<br>
>>><br>
>>> It may also be possible that the or1k port doesn't have the underlying<br>
>>> type<br>
>>><br>
>>> definitions complete or correct.<br>
>>><br>
>>> <a href="http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html" target="_blank">http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html</a><br>
>>><br>
>>> isn't the latest but read() requires ssize_t and size_t to be correctly<br>
>>> and<br>
>>> consistently defined for a target.<br>
>>><br>
>>> You may end up having to reproduce the compile of crt0.c by hand and<br>
>>> change the -c to a -E .. changing the output file.. and see what really<br>
>>> is being preprocessed<br>
>>><br>
>> I did that exactly and I found out that both read and write are prototyped<br>
>> as<br>
>><br>
>> int read (int __fd, void *__buf, size_t __nbyte );<br>
>> int write (int __fd, const void *__buf, size_t __nbyte );<br>
>><br>
>> Also there is another syntax error at crt0.c<br>
>><br>
>> "../../../../../../../newlib-2.1.0-or1k/newlib/libc/sys/rtems/crt0.c:74:37:<br>
>> error: expected ')' before '*' token<br>
>>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"<br>
>><br>
>> When I checked the output of -E I found out the following prototype :<br>
>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int (*(sigset_t<br>
>> *set) = ~(0), 0) { return -1; }<br>
>><br>
> For this error I checked the -E output file and found out that :<br>
> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; is translated to ><br>
> int (*(sigset_t *set) = ~(0), 0) { return -1; }<br>
>><br>
>> and<br>
>> typedef unsigned long sigset_t;<br>
>> is out there.<br>
>><br>
>> (I did not apply newlib-sys-signal-20130532.diff patch, yet, at the RSB<br>
>> which<br>
>>  do nothing with this error)<br>
>>><br>
>>> or1k/newlib port implements some stuff at libgloss (including<br>
>>> or1k/crt0.S)<br>
>>><br>
>>> rtems uses nothing in libgloss.<br>
>>><br>
>>> I just use --target=or1k-xxx --prefix=xxx as configuration options for<br>
>>> newlib.<br>
>>><br>
>>> The RTEMS builds take more. Check rtems-source-builder. Also if you are<br>
>>> not building or1k-rtems tools including binutils and gcc+newlib together<br>
>>> at the same time, it may be causing issues.<br>
>><br>
>> For RSB, I can only see that newlib is linked into gcc directory and then<br>
>> gcc is built with<br>
>> --with-newlib option (what am I missing ?)<br>
>><br>
>> binutils (or1k-rtems4.11-*) is installed<br>
>> and exported at prefix location. The process which I make is<br>
>> 1- Build and install patched binutils-2.24 for RTEMS [successful]<br>
>> 2- Build and install bootstrap patched gcc-4.8.2 [successful]<br>
>> 3- Build and install patched newlib-2.1.0 [stuck here]<br>
>> 4- Build and install patched gcc-4.8.2 with newlib<br>
>><br>
>> Again, this process works fine with --target=or1k-elf and I am able to<br>
>> compile simple<br>
>> hello world program, it only conflicts at the previous 3rd point when<br>
>> targeting<br>
>> or1k-rtems4.11.<br>
>>><br>
>>><br>
>>> Thanks,<br>
>>> Hesham<br>
>>><br>
>>><br>
>>> --<br>
>>> Joel Sherrill, Ph.D.             Director of Research & Development<br>
>>> joel.sherrill@OARcorp.com        On-Line Applications Research<br>
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
>>> Support Available                (256) 722-9985<br>
>><br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> rtems-devel mailing list<br>
> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
><br>
</blockquote></div><br></div></div>