Created attachment 369328 [details, diff] Fix building iPXE with gcc-4.8+ [...] kmk_builtin_append -n "/var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/out/linux.amd64/release/obj/iPxeBaseBin/src/arch/i386/firmware/pcbios/hidemem.o.dep" "" "/var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/src/VBox/Devices/PC/ipxe/src/arch/i386/firmware/pcbios/hidemem.c:" "" /var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/src/VBox/Devices/PC/ipxe/src/arch/i386/firmware/pcbios/bios_console.c: In function ‘bios_putchar’: /var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/src/VBox/Devices/PC/ipxe/src/arch/i386/firmware/pcbios/bios_console.c:195:1: error: bp cannot be used in asm here } ^ /var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/src/VBox/Devices/PC/ipxe/src/arch/i386/firmware/pcbios/bios_console.c:195:1: error: bp cannot be used in asm here kmk: *** [/var/tmp/paludis/app-emulation-virtualbox-4.3.6/work/VirtualBox-4.3.6/out/linux.amd64/release/obj/iPxeBaseBin/src/arch/i386/firmware/pcbios/bios_console.o] Error 1 kmk: *** Waiting for unfinished jobs.... [...] The problem is in the bundled iPXE sources, see URL. Unfortunately, the bundled iPXE sources seem to be outdated and therefore the iPXE patches need some work before they apply. Attached is the patch I came up with, based on the following two from iPXE upstream: https://git.ipxe.org/ipxe.git/commit/cba22d36b77da53890bd65fdadd0e63925687af0 https://git.ipxe.org/ipxe.git/commit/238050dfd46e3c4a87329da1d48b4d8dde5af8a1 could not do any testing yet, though. This bug is basically a dupe of bug #475270
Reported upstream: https://www.virtualbox.org/ticket/13227
fixed in upstream SVN
@Polynomia-C, can we get this in because this bug is blocking gcc-4.8.
(In reply to Anthony Basile from comment #3) > @Polynomia-C, can we get this in because this bug is blocking gcc-4.8. According to the upstream bug this is fixed in virtualbox-4.3.16.
(In reply to Lars Wendler (Polynomial-C) from comment #4) > (In reply to Anthony Basile from comment #3) > > @Polynomia-C, can we get this in because this bug is blocking gcc-4.8. > > According to the upstream bug this is fixed in virtualbox-4.3.16. Should we have <virtualbox-4.3.16 depend on <gcc-4.8?
(In reply to Anthony Basile from comment #5) > (In reply to Lars Wendler (Polynomial-C) from comment #4) > > (In reply to Anthony Basile from comment #3) > > > @Polynomia-C, can we get this in because this bug is blocking gcc-4.8. > > > > According to the upstream bug this is fixed in virtualbox-4.3.16. > > Should we have <virtualbox-4.3.16 depend on <gcc-4.8? I'd prefer stabilizing virtualbox-4.3.18 packages (all seven) alongside with gcc-4.8
Sorry, I meant virtualbox-4.3.16 in my previous comment, not -4.3.18 (which is way too new at the moment).
(In reply to Lars Wendler (Polynomial-C) from comment #6) > (In reply to Anthony Basile from comment #5) > > (In reply to Lars Wendler (Polynomial-C) from comment #4) > > > (In reply to Anthony Basile from comment #3) > > > > @Polynomia-C, can we get this in because this bug is blocking gcc-4.8. > > > > > > According to the upstream bug this is fixed in virtualbox-4.3.16. > > > > Should we have <virtualbox-4.3.16 depend on <gcc-4.8? > > I'd prefer stabilizing virtualbox-4.3.18 packages (all seven) alongside with > gcc-4.8 (In reply to Lars Wendler (Polynomial-C) from comment #7) > Sorry, I meant virtualbox-4.3.16 in my previous comment, not -4.3.18 (which > is way too new at the moment). That's good enough for me. Als long as nothing more needs to be done here to unblock gcc-4.8 we're good.
affected versions are no longer in the tree, and gcc-4.9 is stable now
