Compiling the RTEMS HEAD

Claus, Ric claus at
Wed Jan 26 00:50:21 UTC 2011

On Jan 25, 2011, at 2:15 PM, Joel Sherrill wrote:

> 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=\"\" -DPACKAGE_STRING=\"rtems-tools-schedsim\\" -DPACKAGE_BUGREPORT=\"\" -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 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>

Yes, this is the case.

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

Right.  The patches worked fine.


>> 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.
> 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
> -- 
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill at        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> <schedsim.diff>

More information about the users mailing list