[coreboot] #173: Build faiulre with gcc 4.4.3 because of src/pc80/mc146818rtc_early.c unused variable
coreboot
svn at coreboot.org
Sun Jan 30 20:38:11 CET 2011
#173: Build faiulre with gcc 4.4.3 because of src/pc80/mc146818rtc_early.c unused
variable
--------------------------+--------------------------------------
Reporter: anonymous | Owner: stepan@…
Type: defect | Status: new
Priority: major | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patch Status: there is no patch
--------------------------+--------------------------------------
Hello,
I'm trying to build coreboot with SeaBIOS payload for a qemu x86 platform,
just to give it a try. I've selected the "Use CMOS for configuration
values" option in the General setup menu just as a try (I don't know if
that option is supported by qemu, nor if that's related with my problem
anyway, this is my very first attempt playing around with coreboot) and my
build process stopped with the following error:
[[BR]]
{{{
cc1: warnings being treated as errors[[BR]]
src/pc80/mc146818rtc_early.c: In function 'do_normal_boot':
src/pc80/mc146818rtc_early.c:64: error: unused variable 'i'
make: *** [build/pc80/mc146818rtc_early.romstage.o] Error 1
}}}
[[BR]]
As stated in this ticket summary, I'm using gcc 4.4.3; I'm also building
the stable version of coreboot, retrieved with the command:
[[BR]]
{{{ svn co svn://coreboot.org/coreboot/trunk coreboot }}}
[[BR]]
A closer look to the source file showed me that variable 'i' is only used
within a conditionally compiled block, so I've solved the problem by
simply wrapping that variable declaration in a similar '#if' block as
follows:
[[BR]]
{{{
static inline int do_normal_boot(void)
{
unsigned char byte;
#if CONFIG_USE_CMOS_RECOVERY
int i;
#endif
}}}
[[BR]]
(i could just be moved entirely within the conditional block, according to
coding style preferences)
[[BR]]
Though, I don't know if the above really solves the problem (in case, for
instance, 'CONFIG_USE_CMOS_RECOVERY' should be defined in my configuration
or in general), so that might require some further investigation by
developers actively working on that piece of code (and aware of all
internals).
I'm not sure what kind of priority should be given to this ticket, thus
I'm leaving the default (major) for you to set it more appropriately,
hoping you won't be disappointed about this.
Regards.
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/173>
coreboot <http://www.coreboot.org/>
More information about the coreboot
mailing list