On 06/04/16 14:49, Joel Sherrill wrote:
Newlib has a Linux configuration and we don't assume a lot of the
host. Using newlib as the native libc rather than glibc may solve
these problems.
The only gotcha I can see is that the Linux newlib target has a fair
amount of code in the OS support d
Newlib has a Linux configuration and we don't assume a lot of the host.
Using newlib as the native libc rather than glibc may solve these problems.
The only gotcha I can see is that the Linux newlib target has a fair amount
of code in the OS support directory for Linux. If they replace too much
no
Any ideas / updates / suggestions on this?
Thanking You,
Darshit Shah
Sent from mobile device. Please excuse my brevity
On 01-Apr-2016 4:13 pm, "Darshit Shah" wrote:
> On 03/30, Joel Sherrill wrote:
>
>> On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah wrote:
>>
>> I've started trying to bring the
On 03/30, Joel Sherrill wrote:
On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah wrote:
I've started trying to bring the scheduling simulator in synch with the
current RTEMS master. Joel has created Trac Ticket #2679 (
https://devel.rtems.org/ticket/2679) for this task.
While trying to get the si
On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah wrote:
> I've started trying to bring the scheduling simulator in synch with the
> current RTEMS master. Joel has created Trac Ticket #2679 (
> https://devel.rtems.org/ticket/2679) for this task.
>
> While trying to get the simulator to compile, GCC s
I've started trying to bring the scheduling simulator in synch with the
current RTEMS master. Joel has created Trac Ticket #2679 (
https://devel.rtems.org/ticket/2679) for this task.
While trying to get the simulator to compile, GCC spits out the following
error:
In file included from
/home/thedo
