Bringing the Scheduling Simulator in synch with RTEMS master

Joel Sherrill joel at rtems.org
Wed Mar 30 14:09:20 UTC 2016


On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah <darnir at gmail.com> 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 spits out the following
> error:
>
> In file included from
> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/threadq.h:25:0,
>                  from
> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/thread.h:35,
>                  from
> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/heap.h:22,
>                  from
> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/types.h:26,
>                  from
> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/config.h:24,
>                  from
> /home/thedoctor/Programming/rtems/rtems/cpukit/sapi/include/rtems/config.h:57,
>                  from
> ../../../rtems-schedsim/schedsim/rtems/rtems_init.c:25:
> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/rbtree.h:21:22:
> fatal error: sys/tree.h: No such file or directory
>
> Some scouting around reveals that the sys/tree.h header file is available
> in Newlib. However, I am unable to find a way to point the compiler in that
> direction for the scheduling simulator. Can someone please point me to the
> right set of Automake directives I'd require for this?
>
>
There are two alternatives for missing libc files like this.

1) hope they really aren't needed and ifdef out the include. I suspect this
won't work here.

2) put a copy in schedsim/rtems/sched_cpu/sys. Looks like I hit other
issues like a missing
cpuset.h method and had to add a stub sys/lock.h.

Add a section to the instructions in the ticket. I forgot about this case.

Hopefully this isn't a bad thing to fix. Since you are layering BSD
capabilities on top of
glibc, it can be tricky to avoid naming conflicts.

--joel


>
> --
> Thanking You,
> Darshit Shah
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160330/f04aeff8/attachment-0002.html>


More information about the devel mailing list