Compiling the RTEMS HEAD

Ralf Corsepius ralf.corsepius at
Wed Jan 26 02:09:54 UTC 2011

On 01/25/2011 11: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_STRING=\"rtems-tools-schedsim\\"
>> -DPACKAGE_URL=\"\" -I. -I../../../../RTEMS/tools/schedsim/rtems
>> -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.

The root of the problem is

a) schedsim compiling _rtems-target files_ with the host-compiler
(== flawed design)

b) without schedsim/configure carrying the required c-portabilty checks.
(== immature works)

> RTEMS uses C99,
Wrong ... RTEMS uses gnu99.

> the host compilers on the more recent distributions
> default to C99
No. gnu99

> 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.
Your view - To me it's a poor man's reinvention what was formerly called 

> What is neat about schedsim is that it uses the RTEMS source
> as much as possible with as little adaptation as possible.
 From an integration POV, this is it's fundamental design flaw:

> So this is likely a tools most RTEMS users will not touch. But it
> opens up a world of possibilities.
Have decided to add a configure option which by default disables 
compiling it.

With all due respect, but ATM, this stuff isn't worth bothering users 
with it.


More information about the users mailing list