On Wed, Mar 19, 2014 at 5:04 PM, Gedare Bloom <ged...@rtems.org> wrote:
> On Wed, Mar 19, 2014 at 2:00 AM, Hesham Moustafa > <heshamelmat...@gmail.com> wrote: > > > > > > > > On Wed, Mar 19, 2014 at 3:33 AM, Hesham Moustafa < > heshamelmat...@gmail.com> > > wrote: > >> > >> > >> > >> > >> On Tue, Mar 18, 2014 at 8:26 PM, Joel Sherrill < > joel.sherr...@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. > You'll need to fix the or1k target's definition of ssize_t, not hack > unistd.h. > > I did not hack unitstd.h, instead I changed the return type of read prototype at sys/rtems/crt0.c to int instead of ssize_t. is that acceptable ? > >> > >> 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; } > >> > >> 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 & Development > >>> joel.sherr...@oarcorp.com On-Line Applications Research > >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 > >>> Support Available (256) 722-9985 > >> > >> > > > > > > _______________________________________________ > > 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
