Compiling the RTEMS HEAD

Tue Jan 25 22:15:10 UTC 2011

On 01/25/2011 03:53 PM, Claus, Ric wrote:
> On Jan 24, 2011, at 9:40 PM, Ralf Corsepius wrote:
>
> On 01/25/2011 04:35 AM, Claus, Ric wrote:
> Hi All,
>
>    Back in October, I was able to compile RTEMS out of the box (.bz2 file), however, recently (since at least the turn of the year), I've not been successful.  I have the same trouble with the CVS HEAD.  My target platform is powerpc/virtex.
>
> Below is a dump of the crash.  The version of GCC on a RHEL 5 build machine is:
>
> $ gcc --version
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
>
> I've traced the issue down to the<math.h>   installed on this system wanting to have the __USE_ISOC99 macro defined before it will include<bits/huge_valf.h>   (and various other files).  The simple way out is to define the macro _ISOC99_SOURCE, which will in turn cause the other one to be defined (see<features.h>), but I'll venture that that's probably not the right solution.  Would someone please point me to a proper way to fix this?
>
>    Apologies for the newbe question, but if this is the wrong forum to post such questions, please redirect me.
> No, this list is right.
>
> gcc -DPACKAGE_NAME=\"rtems-tools-schedsim\" -DPACKAGE_TARNAME=\"rtems-tools-schedsim\" -DPACKAGE_VERSION=\"4.10.99.0\" -DPACKAGE_STRING=\"rtems-tools-schedsim\ 4.10.99.0\" -DPACKAGE_BUGREPORT=\"http://www.rtems.org/bugzilla\" -DPACKAGE_URL=\"\" -I. -I../../../../RTEMS/tools/schedsim/rtems  -D__RTEMS_VIOLATE_KERNEL_VISIBILITY__ -I../../../../RTEMS/tools/schedsim/rtems/sched_cpu -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/include -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/score/include -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/score/inline -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/rtems/include -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/rtems/inline -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/sapi/include -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/sapi/inline -I../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libcsupport/include -I../../../../RTEMS/tools/schedsim/rtems/../.
> .!
>   /../cpukit/libmisc/stringto   -g -O2 -MT librtems_a-stringtofloat.o -MD -MP -MF .deps/librtems_a-stringtofloat.Tpo -c -o librtems_a-stringtofloat.o `test -f '../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringtofloat.c' || echo '../../../../RTEMS/tools/schedsim/rtems/'`../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringtofloat.c
> In file included from ../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringtofloat.c:24:
> ../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringto_template.h: In function 'rtems_string_to_float':
> ../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringto_template.h:120: error: 'HUGE_VALF' undeclared (first use in this function)
> ../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringto_template.h:120: error: (Each undeclared identifier is reported only once
> ../../../../RTEMS/tools/schedsim/rtems/../../../cpukit/libmisc/stringto/stringto_template.h:120: error: for each function it appears in.)
> gmake[2]: *** [librtems_a-stringtofloat.o] Error 1
> gmake[2]: Leaving directory `/reg/common/package/rtems/4.11/build/tools/schedsim/rtems'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/reg/common/package/rtems/4.11/build/tools/schedsim'
> make: *** [all-recursive] Error 1
>
> I am able to reproduce this issue on CentOS5.
>
> AFAIS, the immediate cause of your issue is this code tripping over
> c-portability issues originating from the age of RHEL/CentOS5's gcc.
>
> It seems to be an issue with gcc 4.4 as well, which I interpret http://www.rtems.org/wiki/index.php/RTEMS411Ideas to say is sufficient.
>
>
> Apparently, it defaults to std=gnu89, unlike Fedora's gcc which default
> to std=gnu99.
>
> Putting the following in my environment seems to have done the trick:
>
>
> export CC_FOR_HOST=gcc44
> export CFLAGS_FOR_HOST="-g -O2 -std=gnu99"
>
>
> However the actual origins of this issues are deeper.
>
I think this is the root of the cause.  I suspect that -std=gnu99
was optional on that compiler and the default now.  See this
from the math.h on Fedora 14.

/* Get machine-dependent HUGE_VAL value (returned on overflow).
    On all IEEE754 machines, this is +Infinity.  */
#include <bits/huge_val.h>
#ifdef __USE_ISOC99
# include <bits/huge_valf.h>
# include <bits/huge_vall.h>

If you have this in your math.h, then it is just a matter of turning on C99.
Try the attached patch and see if it helps without your environment 
variables
set.

RTEMS uses C99, the host compilers on the more recent distributions
default to C99 and you have an older compiler which has C99 not
as the default.

> For the now, I don't want to elaborate this any further, but bluntly
> speaking, my feel is, schedsim doesn't have any future.
>
> Sorry, I don't know what schedsim is.
>
It is an RTEMS Scheduler Simulator.  After 4.10, RTEMS gained
the ability to have pluggable schedulers.  The scheduler simulator
allows you to develop, test and evaluate new scheduling algorithms
in a predictable and repeatable way on the host.  The pluggable
scheduler has at least a few interesting use cases:

+ necessary to have SMP aware scheduler as alternate to current
    scheduler
+ can have SMP scheduler tuned for < 4, 4-8, 32+ cores, etc.
+ can implement alternative schedulers like Earliest Deadline
    First (EDF).  NOTE: Gedare Bloom has done this one. :)
+ Can have lightweight scheduler implementation for low end
    targets.
+ Can implement your own scheduler and evaluate it.

The latter capability is really interesting from a real-time
research viewpoint and I personally expect it to be useful
as we find the right set of SMP aware scheduling algorithms.
The simulator lets you see how an algorithm does with varying
configurations (e.g. 2 core, 256 cores, etc)

The idea of a scheduler simulator is not knew and there is
LinSched for Linux.

http://www.osnews.com/story/23897/LinSched_a_Userspace_Linux_Scheduler_Simulator

What is neat about schedsim is that it uses the RTEMS source
as much as possible with as little adaptation as possible.  So
it should have a fairly high fidelity compared to running on
real hardware.

So this is likely a tools most RTEMS users will not touch.  But it
opens up a world of possibilities.
> Ric
>
>
> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: schedsim.diff
URL: <http://lists.rtems.org/pipermail/users/attachments/20110125/5c4b7327/attachment-0001.ksh>