Fwd: Conflict when modifying newlib/openrisc to work for RTEMS

[Hesham Moustafa]

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

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.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140319/212f5511/attachment-0001.html>