Compiling the RTEMS HEAD

[Claus, Ric]

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.

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.

Ric


Ralf