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. > 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 & >> developmentjoel.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
