Compiling the RTEMS HEAD

[Ralf Corsepius]

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

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 
the POSIX-BSP.

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


Ralf