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 )); 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; } 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
