On Mon, Apr 28, 2014 at 6:32 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > On 4/28/2014 11:25 AM, Hesham Moustafa wrote: >> Thanks! These patches really help. I've already reverted back to the >> original read/write prototypes after defining __rtems__ and it works. >> Now newlib works normally (with the non-GPL patch you provided before >> and my modifications). The only issues I have to make some workarounds >> for are related to some POSIX macros. i.e, >> >> NAME_MAX (at newlib/libc/sys/rtems/sys/dirent.h) >> PATH_MAX (at newlib/libc/posix/collate.c) >> _POSIX2_RE_DUP_MAX (at newlib/libc/posix/utils.h) >> >> I got undefined macro errors for these three macros, thus, I had to >> add some #ifndef XXX statements earlier at the container files, to get >> over there errors. > I suspect that was for not having __rtems__ defined. Revert them > and try. I don't see NAME_MAX hacked on in my source so you > must not have them committed. > > Also there are some header files in sys/rtems. If those are not the > ones installed, then the build still has problems. But I suspect that > is OK no > > I used the patch on your github and you got my diff. > > FYI all of the code in newlib/libc/machine/or1k is totally completely > unacceptable to newlib from a license perspective. It is GPL v3 and > totally unacceptable to RTEMS as well. > Yes I got that. By "the patch you provided" I mean this one [1]. I no longer use the patch on my github account anymore. Soon, I will submit the new newlib patch for review and to discuss about it.
[1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch > And besides, two of the three files in there don't believe in libc > at all. So we need a BSD-ish licensed setjmp/longjmp. >> >> On Mon, Apr 28, 2014 at 6:02 PM, Joel Sherrill >> <joel.sherr...@oarcorp.com> wrote: >>> Hi >>> >>> I am not sure I got everything fixed but it should be a lot >>> better now. See the attached diffs. >>> >>> + libgcc - patterns were in the wrong order and or1k*-*-rtems* >>> or1k*-*-* was before rtems stanza >>> + config/or1k - moved elf.h to rtemself.h. There should be >>> a target OS independent config/or1k/elf.h >>> Also fixed or1k/rtemself.h so it defines CPP predefines >>> including __rtems__ which explains your compilation problem. >>> + newlib/.../rtems/crt0 had wrong prototypes for write() and >>> read(). >>> >>> These are diffs against the sources with your patches applied. >>> >>> Apply on top of yours. >>> >>> It is still building here after clobbering the tree and starting >>> over so there may be more problems but this should be >>> a good start. :) >>> >>> --joel >>> >>> >>> On 4/27/2014 7:26 PM, Joel Sherrill wrote: >>>> This is a bug in your gcc port. You need to ensure that __rtems__ is >>>> defined. >>>> >>>> See >>>> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff >>>> around 220 and compare it to >>>> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD >>>> >>>> That defines __rtems__. Without that, the .h files in newlib don't get the >>>> right settings. >>>> ________________________________________ >>>> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On >>>> Behalf Of Joel Sherrill [joel.sherr...@oarcorp.com] >>>> Sent: Sunday, April 27, 2014 7:17 PM >>>> To: Hesham Moustafa >>>> Cc: rtems-devel@rtems.org >>>> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset >>>> >>>> On Apr 27, 2014 6:40 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: >>>>> On Apr 27, 2014 5:12 PM, Hesham Moustafa <heshamelmat...@gmail.com> wrote: >>>>>> Hi all, >>>>>> >>>>>> When I am trying to get newlib compiled while porting newlib to >>>>>> rtems/or1k, I met an error that confused me. The error happens for me >>>>>> with both: Ubuntu and Fedora. Also it arises when configuring and >>>>>> building a standalone newlib library (with configure >>>>>> --target=or1k-rtems4.11) or when building gcc with newlib (for the >>>>>> same target). By commenting that line, newlib and gcc building process >>>>>> works fine. >>>>>> >>>>>> The error is: >>>>>> >>>>>> "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37: >>>>>> error: expected ‘)’ before ‘*’ token >>>>>> RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })" >>>>>> >>>>>> By expanding the macros with -E option, I got the following expansion >>>>>> for the corresponding function: >>>>>> >>>>>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int >>>>>> (*(sigset_t *set) = ~(0), 0) { return -1; } >>>>>> >>>>>> Does that make sense? >>>>>> >>>>>> I searched for anyone that happened to have the same problem and I >>>>>> found this link [1] related to compiling rtems/newlib for microblaze >>>>> This is a new architecture for RTEMS+newlib combination. I recall that >>>>> there is a configure script near the top of newlib and it needs an entry >>>>> for thus target. Or a pattern needs adjusting to distinguish or1k*-*-* >>>>> from the RTEMS variant. >>>> This can also be because the path through signal.h is skipping something >>>> based on or1k. >>>> >>>> What source are you using as base to modify? I need to clone all your >>>> source and try it myself. >>>> >>>>>> [1] http://sourceware.org/ml/newlib/2012/msg00529.html >>>>>> >>>>>> Regards, >>>>>> Hesham >>>>>> >>>>>> _______________________________________________ >>>>>> rtems-devel mailing list >>>>>> rtems-devel@rtems.org >>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>> -- >>> 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 >>> > > -- > 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