Conflict when modifying newlib/openrisc to work for RTEMS

[Hesham Moustafa]

On Wed, Mar 19, 2014 at 5:04 PM, Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, Mar 19, 2014 at 2:00 AM, Hesham Moustafa
> <heshamelmatary at gmail.com> wrote:
> >
> >
> >
> > On Wed, Mar 19, 2014 at 3:33 AM, Hesham Moustafa <
> heshamelmatary at gmail.com>
> > wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Mar 18, 2014 at 8:26 PM, Joel Sherrill <
> joel.sherrill at 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.sherrill at 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 at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140319/676fe263/attachment-0001.html>