On Wed, Mar 19, 2014 at 11:56 AM, Hesham Moustafa <heshamelmat...@gmail.com> wrote: > > > > 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 ? Probably not. You should avoid making RTEMS code cater to the missing feature in some specific target, eg or1k here. Other RTEMS toolchains define ssize_t correctly for this read prototype, so the toolchain you provide for or1k also should.
>> >> >> >> >> 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
