Building VSA on a Slackware 11.0 system gives these errors (See script output, might be long.)
Hello! On my Slackware 11.0 system I decided to see if the recently released OpenVSA code would build on my system. I've had some good successes in building the utilities from the regular Coreboot repositories for say figuring out what the hosted system is using, so I thought I'd see if this recent arrival would build.
Build process continues as described in the script file that begins here: Script started on Mon 11 Feb 2008 01:19:00 PM EST root@jimkirk:/usr/src/lobos/openvsa# make make -C sysmgr vsainit.bin make[1]: Entering directory `/usr/src/lobos/openvsa/sysmgr' ../smimac.pl < init.S > tmp_init.S && gcc -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -c -o init.o tmp_init.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o cpu_init.o cpu_init.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o chip.o chip.S chip.S: Assembler messages: chip.S:88: Warning: line numbers must be positive; line number 0 rejected ld --cref --oformat binary -Map vsainit.map \ -o vsainit.bin -T vsainit.lnk init.o cpu_init.o chip.o make[1]: Leaving directory `/usr/src/lobos/openvsa/sysmgr' make -C sysmgr sysmgr.vsm make[1]: Entering directory `/usr/src/lobos/openvsa/sysmgr' ../smimac.pl < sysmgr.S > tmp_sysmgr.S && gcc -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -c -o sysmgr.o tmp_sysmgr.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o bugs.o bugs.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o utils.o utils.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o syscalls.o syscalls.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o smis.o smis.S smis.S: Assembler messages: smis.S:153: Warning: line numbers must be positive; line number 0 rejected ../smimac.pl < port92.S > tmp_port92.S && gcc -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -c -o port92.o tmp_port92.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o sw_int.o sw_int.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o debug.o debug.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o vr_misc.o vr_misc.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o cpu.o cpu.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o idt.o idt.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o message.o message.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o msr.o msr.S gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o events.o events.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o handlers.o handlers.c gcc -march=i586 -I../inc -I../sysmgr -MD -c -o chipset.o chipset.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o gpio.o gpio.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o errors.o errors.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o history.o history.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o io.o io.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o virt_pci.o virt_pci.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o mbus.o mbus.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o vsa_init.o vsa_init.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o descr.o descr.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o vr.o vr.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o topology.o topology.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o pci_rd.o pci_rd.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o pci_wr.o pci_wr.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o cs5536.o cs5536.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o swapsif.o swapsif.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o unregstr.o unregstr.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o mdd.o mdd.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o pci_pm.o pci_pm.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o mfgpt.o mfgpt.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o mapper.o mapper.c gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o timeout.o timeout.c timeout.c: In function `Set_MBus_IO_Timeout': timeout.c:372: warning: 'PhysPtr' might be used uninitialized in this function make[1]: *** [timeout.o] Error 1 make[1]: Leaving directory `/usr/src/lobos/openvsa/sysmgr' make: *** [sysmgr/sysmgr.vsm] Error 2 root@jimkirk:/usr/src/lobos/openvsa# exit
Script done on Mon 11 Feb 2008 01:19:18 PM EST
Is that normal? And what else should be done to continue? -- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi
Gregg C Levine wrote:
Hello! On my Slackware 11.0 system I decided to see if the recently released OpenVSA code would build on my system.
root@jimkirk:/usr/src/lobos/openvsa# make
You are very trusting to build a newly-seeded experimental tree as root!
make -C sysmgr vsainit.bin make[1]: Entering directory `/usr/src/lobos/openvsa/sysmgr'
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o chip.o chip.S chip.S: Assembler messages: chip.S:88: Warning: line numbers must be positive; line number 0 rejected
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o smis.o smis.S smis.S: Assembler messages: smis.S:153: Warning: line numbers must be positive; line number 0 rejected
I'm not sure why these occur. I was unable to reproduce these warnings, and I am not sure where line numbers are even brought into the picture...
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o timeout.o timeout.c timeout.c: In function `Set_MBus_IO_Timeout': timeout.c:372: warning: 'PhysPtr' might be used uninitialized in this function make[1]: *** [timeout.o] Error 1 make[1]: Leaving directory `/usr/src/lobos/openvsa/sysmgr' make: *** [sysmgr/sysmgr.vsm] Error 2
I had originally turned on '-Wall -Werror' to ensure that any non-standard C-language constructs in the VSA that was accepted by Microsoft C would have a higher chance of being caught by the OpenVSA build. In this case it seems like a relatively harmless warning led to breakage.
Is that normal? And what else should be done to continue?
No it is not normal. The problem does not exhibit itself under GCC 4.1.0.
I see that Slackware 11.0 ships GCC 3.4.6. I was able to reproduce the problem with gcc34 on Fedora.
Please see the mailing list for trivial patch that fixes this build issue.
Chris.
Hello! Chris, I trust the gang behind the Coreboot team to create code that won't want to fry my target boards, that of course is when they get here.
But to build stuff as root, well, there is a story there, for the crosstool compiler that Dan Kegel created I always do that as an ordinary user.
The Coreboot code blobs, well that's another one, I'll probably try that patch when it arrives. And for our VSA creation, I just tried it as normal user. It, ah, repeats. -- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi
-----Original Message----- From: Chris Kilgour [mailto:techie@whiterocker.com] Sent: Monday, February 11, 2008 10:11 PM To: Gregg C Levine Cc: coreboot@coreboot.org Subject: Re: [coreboot] Building VSA on a Slackware 11.0 system gives
these errors (See
script output, might be long.)
Gregg C Levine wrote:
Hello! On my Slackware 11.0 system I decided to see if the recently released OpenVSA code would build on my system.
root@jimkirk:/usr/src/lobos/openvsa# make
You are very trusting to build a newly-seeded experimental tree as root!
make -C sysmgr vsainit.bin make[1]: Entering directory `/usr/src/lobos/openvsa/sysmgr'
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o chip.o chip.S chip.S: Assembler messages: chip.S:88: Warning: line numbers must be positive; line number 0
rejected
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o smis.o smis.S smis.S: Assembler messages: smis.S:153: Warning: line numbers must be positive; line number 0
rejected
I'm not sure why these occur. I was unable to reproduce these warnings, and I am not sure where line numbers are even brought into the picture...
gcc -c -Wall -Werror -fno-strict-aliasing -march=i586 -Os -I../inc -I../sysmgr -MD -o timeout.o timeout.c timeout.c: In function `Set_MBus_IO_Timeout': timeout.c:372: warning: 'PhysPtr' might be used uninitialized in this function make[1]: *** [timeout.o] Error 1 make[1]: Leaving directory `/usr/src/lobos/openvsa/sysmgr' make: *** [sysmgr/sysmgr.vsm] Error 2
I had originally turned on '-Wall -Werror' to ensure that any non-standard C-language constructs in the VSA that was accepted by Microsoft C would have a higher chance of being caught by the OpenVSA build. In this case it seems like a relatively harmless warning led to breakage.
Is that normal? And what else should be done to continue?
No it is not normal. The problem does not exhibit itself under GCC 4.1.0.
I see that Slackware 11.0 ships GCC 3.4.6. I was able to reproduce the problem with gcc34 on Fedora.
Please see the mailing list for trivial patch that fixes this build issue.
Chris.
-
Chris Kilgour -
Gregg C Levine