Compiling the RTEMS HEAD
claus at slac.stanford.edu
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=\"188.8.131.52\" -DPACKAGE_STRING=\"rtems-tools-schedsim\ 184.108.40.206\" -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: *** [librtems_a-stringtofloat.o] Error 1
>> gmake: Leaving directory `/reg/common/package/rtems/4.11/build/tools/schedsim/rtems'
>> gmake: *** [all-recursive] Error 1
>> gmake: 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>
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
> 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
> + 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
> + 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.
>> rtems-users mailing list
>> rtems-users at rtems.org
> 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
More information about the users