x86_64-pc-linux-gnu-g++ -c -O2 -fno-pie -nostdinc -iwithprefix include -include /lib/modules/4.9.0/build/include/linux/kconfig.h -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-unused-parameter -Wlogical-op -Wno-variadic-macros -Wno-sign-compare -fdiagnostics-show-option -fno-stack-protector -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fno-common -include /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/include/VBox/VBoxGuestMangling.h -m64 -mno-red-zone -mcmodel=kernel -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-reorder-blocks -fno-asynchronous-unwind-tables -funit-at-a-time -Wno-sign-compare -fno-exceptions -fno-rtti -include /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/include/VBox/VBoxGuestMangling.h -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/src/VBox/Runtime/r0drv/linux -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/src/VBox/Runtime -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/src/VBox/Runtime/include -I/lib/modules/4.9.0/build/include -I/lib/modules/4.9.0/build/include/asm-i386/mach-default -I/lib/modules/4.9.0/build/include/asm-x86/mach-default -I/lib/modules/4.9.0/build/include/drm -I/lib/modules/4.9.0/build/arch/x86/include -I/lib/modules/4.9.0/build/arch/x86/include/asm/mach-default -I/lib/modules/4.9.0/build/arch/x86/include/uapi -I/lib/modules/4.9.0/build/arch/x86/include/generated -I/lib/modules/4.9.0/build/arch/x86/include/generated/uapi -I/lib/modules/4.9.0/build/include/uapi -I/lib/modules/4.9.0/build/include/generated/uapi -I/lib/modules/4.9.0/build/include -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/out/linux.amd64/release/obj/RuntimeGuestR0/dtrace -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/include -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/out/linux.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_REM -DVBOX_WITH_RAW_MODE -DRT_OS_LINUX -D_FILE_OFFSET_BITS=64 -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/opt/VirtualBox\" -DRTPATH_APP_PRIVATE_ARCH=\"/opt/VirtualBox\" -DRTPATH_SHARED_LIBS=\"/opt/VirtualBox\" -DRTPATH_APP_DOCS=\"/opt/VirtualBox\" -DIN_RING0 -DIN_RT_R0 -DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -D__KERNEL__ -DMODULE -DIN_GUEST -DIN_GUEST_R0 -DIN_RT_R0 -DRT_WITH_VBOX -DRT_WITHOUT_NOCRT_WRAPPERS -DRT_NO_EXPORT_SYMBOL -DNOFILEID -DRT_NO_EXPORT_SYMBOL -DMODULE -DKBUILD_MODNAME=KBUILD_STR\(vboxdrv\) -DKBUILD_BASENAME=KBUILD_STR\(vboxdrv\) -DIN_SUP_R0 -Wp,-MD,/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/out/linux.amd64/release/obj/RuntimeGuestR0/common/checksum/alt-md5.o.dep -Wp,-MT,/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/out/linux.amd64/release/obj/RuntimeGuestR0/common/checksum/alt-md5.o -Wp,-MP -o /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/out/linux.amd64/release/obj/RuntimeGuestR0/common/checksum/alt-md5.o /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/src/VBox/Runtime/common/checksum/alt-md5.cpp In file included from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/include/iprt/types.h:140:0, from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/include/iprt/mem.h:31, from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.1.12/work/VirtualBox-5.1.12/src/VBox/Runtime/common/alloc/alloc.cpp:34: /lib/modules/4.9.0/build/arch/x86/include/asm/atomic.h: In function 'int atomic_read(const atomic_t*)': /lib/modules/4.9.0/build/include/linux/compiler.h:305:42: error: uninitialized const member in 'union atomic_read(const atomic_t*)::<anonymous>' union { typeof(x) __val; char __c[1]; } __u; \ ^ /lib/modules/4.9.0/build/include/linux/compiler.h:312:22: note: in expansion of macro '__READ_ONCE' #define READ_ONCE(x) __READ_ONCE(x, 1) ^
Created attachment 457128 [details] build log xz-compressed
Unfortunately, the same is true for version 5.1.14
Builds with 4.4 kernel, but not with 4.9.
The compilation fails only on 64 bit (x86-64) guests. On 32 bit (x86) guests it compiles without errors.
Created attachment 462468 [details] archive of build.log, environment, emerge --info and emerge -pqv Not sure whether it's the same issue, stable app-emulation/virtualbox-guest-additions-5.0.32 fails to build with stable sys-kernel/gentoo-sources-4.9.6-r1, though as the error is the same, figured it would be better to add info here than to open a new bug. x86_64-pc-linux-gnu-g++ -c -O2 -fno-pie -nostdinc -iwithprefix include -include /lib/modules/4.9.6-gentoo-r1/build/include/linux/kconfig.h -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-unused-parameter -Wlogical-op -Wno-sign-compare -fdiagnostics-show-option -fno-stack-protector -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fno-common -include /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/include/VBox/VBoxGuestMangling.h -m64 -mno-red-zone -mcmodel=kernel -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-reorder-blocks -fno-asynchronous-unwind-tables -funit-at-a-time -Wno-sign-compare -fno-exceptions -fno-rtti -include /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/include/VBox/VBoxGuestMangling.h -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/src/VBox/Runtime/r0drv/linux -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/src/VBox/Runtime -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/src/VBox/Runtime/include -I/lib/modules/4.9.6-gentoo-r1/build/include -I/lib/modules/4.9.6-gentoo-r1/build/include/asm-i386/mach-default -I/lib/modules/4.9.6-gentoo-r1/build/include/asm-x86/mach-default -I/lib/modules/4.9.6-gentoo-r1/build/include/drm -I/lib/modules/4.9.6-gentoo-r1/build/arch/x86/include -I/lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/mach-default -I/lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/uapi -I/lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/generated -I/lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/generated/uapi -I/lib/modules/4.9.6-gentoo-r1/build/include/uapi -I/lib/modules/4.9.6-gentoo-r1/build/include/generated/uapi -I/lib/modules/4.9.6-gentoo-r1/build/include -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/out/linux.amd64/release/obj/RuntimeGuestR0/dtrace -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/include -I/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/out/linux.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_DEBUGGER -DRT_OS_LINUX -D_FILE_OFFSET_BITS=64 -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/opt/VirtualBox\" -DRTPATH_APP_PRIVATE_ARCH=\"/opt/VirtualBox\" -DRTPATH_SHARED_LIBS=\"/opt/VirtualBox\" -DRTPATH_APP_DOCS=\"/opt/VirtualBox\" -DIN_RING0 -DIN_RT_R0 -DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -D__KERNEL__ -DMODULE -DIN_GUEST -DIN_GUEST_R0 -DIN_RT_R0 -DRT_WITH_VBOX -DRT_WITHOUT_NOCRT_WRAPPERS -DRT_NO_EXPORT_SYMBOL -DRT_NO_EXPORT_SYMBOL -DMODULE -DKBUILD_MODNAME=KBUILD_STR\(vboxdrv\) -DKBUILD_BASENAME=KBUILD_STR\(vboxdrv\) -DIN_SUP_R0 -Wp,-MD,/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/out/linux.amd64/release/obj/RuntimeGuestR0/common/alloc/heapoffset.o.dep -Wp,-MT,/var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/out/linux.amd64/release/obj/RuntimeGuestR0/common/alloc/heapoffset.o -Wp,-MP -o /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/out/linux.amd64/release/obj/RuntimeGuestR0/common/alloc/heapoffset.o /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/src/VBox/Runtime/common/alloc/heapoffset.cpp In file included from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/include/iprt/types.h:116:0, from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/include/iprt/heap.h:30, from /var/tmp/portage/app-emulation/virtualbox-guest-additions-5.0.32/work/VirtualBox-5.0.32/src/VBox/Runtime/common/alloc/heapsimple.cpp:32: /lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/atomic.h: In function ‘int atomic_read(const atomic_t*)’: /lib/modules/4.9.6-gentoo-r1/build/include/linux/compiler.h:305:42: error: uninitialized const member in ‘union atomic_read(const atomic_t*)::<anonymous>’ union { typeof(x) __val; char __c[1]; } __u; \ ^ Note, app-emulation/virtualbox-guest-additions-5.0.32 builds with sys-kernel/gentoo-sources-4.4.39, and VBoxLinuxAdditions.run (from the guest additions iso) successfully builds guest modules for sys-kernel/gentoo-sources-4.9.6-r1.
Can confirm: Error happens with kernel 4.9.x on x86-64 Did not happen with kernel 4.8.x gcc and glibc were the same for both kernels gcc: 5.4.0-r3 glibc: 2.23-r3
This is an issue that - according to upstream - will not be fixed anytime soon. So I suggest to use 4.4 LTS kernel for Gentoo guests VMs for the time being.
Is there a bug report upstream for this? I can't find any. From what I can find, guest additions >=5.1.12 is supposed to work with kernel 4.9. (https://www.virtualbox.org/ticket/16155)
(In reply to BobbyK from comment #5) Have the same problem building virtualbox-guest-additions-5.0.32 with kernel 4.9.6-r1 and gcc-4.9.4 as reported by BobbyK.
Posted a potential fix in the wrong bug: https://bugs.gentoo.org/show_bug.cgi?id=607480 Head over if you are interested.
(In reply to Joakim Tjernlund from comment #10) > Posted a potential fix in the wrong bug: > https://bugs.gentoo.org/show_bug.cgi?id=607480 > Head over if you are interested. I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund from comment #10) > Posted a potential fix in the wrong bug: > https://bugs.gentoo.org/show_bug.cgi?id=607480 > Head over if you are interested. I tried the 3 patches out, but build still fails with same atomic_read error.
(In reply to Nathan Torchia from comment #11) > (In reply to Joakim Tjernlund from comment #10) > > Posted a potential fix in the wrong bug: > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > Head over if you are interested. > > I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund > from comment #10) > > Posted a potential fix in the wrong bug: > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > Head over if you are interested. > > I tried the 3 patches out, but build still fails with same atomic_read error. hmm, what are you bulding with ? Make sure you have the patches propely applied everywhere, throw the patches into /etc/portage/patches/sys-kernel/vanilla-sources/ (or gentoo-sources) and remerge the kernel.
seems like xf85-virtualbox-video need the same ebuild fixes
@Joakim, Thanks, it works! My WM booted with kernel-4.9.6. VB additions work properly.
(In reply to Rion from comment #14) > @Joakim, Thanks, it works! > > My WM booted with kernel-4.9.6. VB additions work properly. Good :) The kernel patches I could try to upstream, I hope they are acceptable for main stream linux too but it will take time I guess before they will find its way back to 4.9 The ebuild stuff just used trial and error, maybe there is a better way to add that?
Nope. Patched kernel, rebooted, run modified ebuilds. Now I get a bunch of warnings like: In file included from /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/types.h:140:0, from /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/mem.h:31, from /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34: /lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/atomic.h: In function ‘int atomic_read(const atomic_t*)’: /lib/modules/4.9.6-gentoo-r1/build/include/linux/compiler.h:316:41: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 union { typeof(x) __val; char __c[1]={0}; } __u; \ ^ /lib/modules/4.9.6-gentoo-r1/build/include/linux/compiler.h:324:22: note: in expansion of macro ‘__READ_ONCE’ #define READ_ONCE(x) __READ_ONCE(x, 1) ^ /lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/atomic.h:26:9: note: in expansion of macro ‘READ_ONCE’ return READ_ONCE((v)->counter); and then: /lib/modules/4.9.6-gentoo-r1/build/include/asm-generic/bitops/le.h: In function ‘long unsigned int find_next_zero_bit_le(const void *, long unsigned int, long unsigned int)’: /lib/modules/4.9.6-gentoo-r1/build/include/asm-generic/bitops/le.h:14:46: error: invalid conversion from ‘const void*’ to ‘const long unsigned int*’ [-fpermissive] return find_next_zero_bit(addr, size, offset); :-(
(In reply to Paolo Pedroni from comment #16) > Nope. Patched kernel, rebooted, run modified ebuilds. Now I get a bunch of > warnings like: > > In file included from > /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5. > 1.14/include/iprt/types.h:140:0, > from > /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5. > 1.14/include/iprt/mem.h:31, > from > /var/tmp/portage/x11-drivers/xf86-video-virtualbox-5.1.14/work/VirtualBox-5. > 1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34: > /lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/atomic.h: In > function ‘int atomic_read(const atomic_t*)’: > /lib/modules/4.9.6-gentoo-r1/build/include/linux/compiler.h:316:41: warning: > non-static data member initializers only available with -std=c++11 or > -std=gnu++11 > union { typeof(x) __val; char __c[1]={0}; } __u; \ > ^ > /lib/modules/4.9.6-gentoo-r1/build/include/linux/compiler.h:324:22: note: in > expansion of macro ‘__READ_ONCE’ > #define READ_ONCE(x) __READ_ONCE(x, 1) > ^ > /lib/modules/4.9.6-gentoo-r1/build/arch/x86/include/asm/atomic.h:26:9: note: > in expansion of macro ‘READ_ONCE’ > return READ_ONCE((v)->counter); > > and then: > > /lib/modules/4.9.6-gentoo-r1/build/include/asm-generic/bitops/le.h: In > function ‘long unsigned int find_next_zero_bit_le(const void > *, long unsigned int, long unsigned int)’: > /lib/modules/4.9.6-gentoo-r1/build/include/asm-generic/bitops/le.h:14:46: > error: invalid conversion from ‘const void*’ to ‘const long unsigned int*’ > [-fpermissive] > return find_next_zero_bit(addr, size, offset); > > :-( Scratch that. I forgot to modify the xf86-video-virtualbox ebuild. Stupid me!
@Joakim, Thanks, it now works!
(In reply to Joakim Tjernlund from comment #12) > (In reply to Nathan Torchia from comment #11) > > (In reply to Joakim Tjernlund from comment #10) > > > Posted a potential fix in the wrong bug: > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > Head over if you are interested. > > > > I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund > > from comment #10) > > > Posted a potential fix in the wrong bug: > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > Head over if you are interested. > > > > I tried the 3 patches out, but build still fails with same atomic_read error. > > hmm, what are you bulding with ? > Make sure you have the patches propely applied everywhere, throw > the patches into /etc/portage/patches/sys-kernel/vanilla-sources/ > (or gentoo-sources) and remerge the kernel. Whew, okay, I figured it out. I'm using GCC 6.3.0 which has some new C++ stuff enabled by default. I was getting an error like: "error: use of deleted function". So I changed the patch to: union _u { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; It just includes a default ctor. And it all compiles fine now.
*** Bug 607480 has been marked as a duplicate of this bug. ***
*** Bug 610342 has been marked as a duplicate of this bug. ***
(In reply to Nathan Torchia from comment #19) > (In reply to Joakim Tjernlund from comment #12) > > (In reply to Nathan Torchia from comment #11) > > > (In reply to Joakim Tjernlund from comment #10) > > > > Posted a potential fix in the wrong bug: > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > Head over if you are interested. > > > > > > I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund > > > from comment #10) > > > > Posted a potential fix in the wrong bug: > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > Head over if you are interested. > > > > > > I tried the 3 patches out, but build still fails with same atomic_read error. > > > > hmm, what are you bulding with ? > > Make sure you have the patches propely applied everywhere, throw > > the patches into /etc/portage/patches/sys-kernel/vanilla-sources/ > > (or gentoo-sources) and remerge the kernel. > > > Whew, okay, I figured it out. I'm using GCC 6.3.0 which has some new C++ > stuff enabled by default. I was getting an error like: "error: use of > deleted function". So I changed the patch to: > > union _u { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; > > It just includes a default ctor. And it all compiles fine now. I get with gcc 4.9.4: /lib/modules/4.9.11/build/include/linux/compiler.h:316:13: warning: ISO C++ forbids declaration of ‘_u’ with no type [-fpermissive] union { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; Could we do better(I don't know C++)?
(In reply to Joakim Tjernlund from comment #22) > (In reply to Nathan Torchia from comment #19) > > (In reply to Joakim Tjernlund from comment #12) > > > (In reply to Nathan Torchia from comment #11) > > > > (In reply to Joakim Tjernlund from comment #10) > > > > > Posted a potential fix in the wrong bug: > > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > > Head over if you are interested. > > > > > > > > I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund > > > > from comment #10) > > > > > Posted a potential fix in the wrong bug: > > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > > Head over if you are interested. > > > > > > > > I tried the 3 patches out, but build still fails with same atomic_read error. > > > > > > hmm, what are you bulding with ? > > > Make sure you have the patches propely applied everywhere, throw > > > the patches into /etc/portage/patches/sys-kernel/vanilla-sources/ > > > (or gentoo-sources) and remerge the kernel. > > > > > > Whew, okay, I figured it out. I'm using GCC 6.3.0 which has some new C++ > > stuff enabled by default. I was getting an error like: "error: use of > > deleted function". So I changed the patch to: > > > > union _u { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; > > > > It just includes a default ctor. And it all compiles fine now. > > I get with gcc 4.9.4: > /lib/modules/4.9.11/build/include/linux/compiler.h:316:13: warning: ISO C++ > forbids declaration of ‘_u’ with no type [-fpermissive] > union { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; > > Could we do better(I don't know C++)? Or this: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 union { void _u(){}; typeof(x) __val; char __c[1]={0}; } __u;
(In reply to Joakim Tjernlund from comment #23) > (In reply to Joakim Tjernlund from comment #22) > > (In reply to Nathan Torchia from comment #19) > > > (In reply to Joakim Tjernlund from comment #12) > > > > (In reply to Nathan Torchia from comment #11) > > > > > (In reply to Joakim Tjernlund from comment #10) > > > > > > Posted a potential fix in the wrong bug: > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > > > Head over if you are interested. > > > > > > > > > > I tried the 3 patches, but I still get the (In reply to Joakim Tjernlund > > > > > from comment #10) > > > > > > Posted a potential fix in the wrong bug: > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=607480 > > > > > > Head over if you are interested. > > > > > > > > > > I tried the 3 patches out, but build still fails with same atomic_read error. > > > > > > > > hmm, what are you bulding with ? > > > > Make sure you have the patches propely applied everywhere, throw > > > > the patches into /etc/portage/patches/sys-kernel/vanilla-sources/ > > > > (or gentoo-sources) and remerge the kernel. > > > > > > > > > Whew, okay, I figured it out. I'm using GCC 6.3.0 which has some new C++ > > > stuff enabled by default. I was getting an error like: "error: use of > > > deleted function". So I changed the patch to: > > > > > > union _u { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; > > > > > > It just includes a default ctor. And it all compiles fine now. > > > > I get with gcc 4.9.4: > > /lib/modules/4.9.11/build/include/linux/compiler.h:316:13: warning: ISO C++ > > forbids declaration of ‘_u’ with no type [-fpermissive] > > union { _u(){}; typeof(x) __val; char __c[1]={0}; } __u; > > > > Could we do better(I don't know C++)? > > Or this: > warning: non-static data member initializers only available with -std=c++11 > or -std=gnu++11 > union { void _u(){}; typeof(x) __val; char __c[1]={0}; } __u; How about: union { void _u(void){}; typeof(x) __val; char __c[1]; } __u={0}; Just guessing though.
Created attachment 464534 [details, diff] remove extern decl.
Created attachment 464536 [details, diff] Uninitialized C++ const issue
I just sent these two patches upstream, lets see what they think. Meanwhile perhaps this diff could be included in the two ebuilds: --- /usr/portage/app-emulation/virtualbox-guest-additions/virtualbox-guest-additions-5.1.14.ebuild 2017-01-18 02:39:05.000000000 +0100 +++ /var/lib/layman/transmode/app-emulation/virtualbox-guest-additions/virtualbox-guest-additions-5.1.14-r1.ebuild 2017-02-21 15:42:58.723210789 +0100 @@ -122,7 +122,8 @@ MAKE="kmk" \ emake TOOL_YASM_AS=yasm \ VBOX_ONLY_ADDITIONS=1 \ - KBUILD_VERBOSE=2 + KBUILD_VERBOSE=2 \ + CXXFLAGS="${CXXFLAGS} -fpermissive -D__builtin_types_compatible_p\(x,y\)=1"
With gcc-6.3.0, glibc-2.25 und linux-4.10.0 I use union { void _u(){}; typeof(x) __val; char __c[1]={0}; } __u={0}; in the (patched) kernel headers and KBUILD_VERBOSE=2 \ CXXFLAGS="${CXXFLAGS} -fpermissive -D__builtin_types_compatible_p (x,y\)=1" In addition, due to https://github.com/torvalds/linux/commit/dfeef68862edd7d4bafe68ef7aeb5f658ef24bb5 I had to add the sed-command in src_prepare (see below) src_prepare() { # PaX fixes (see bug #298988) pushd "${WORKDIR}" &>/dev/null || die eapply "${FILESDIR}"/vboxguest-4.1.0-log-use-c99.patch epatch "${FILESDIR}"/${P}-glibc-2.24.patch sed -i -e'/ .readlink = generic_readlink,/d' vboxsf/lnkops.c VirtualBox-5.1.14/src/VBox/Additions/linux/sharedfolders/lnkops.c popd &>/dev/null || die With all of these modifications, virtualbox-guest-additions-5.1.14 finally emerged successfully.
(In reply to Helmut Jarausch from comment #28) > With gcc-6.3.0, glibc-2.25 und linux-4.10.0 > > I use > > union { void _u(){}; typeof(x) __val; char __c[1]={0}; } __u={0}; Very close to my last patch, but the __c[1]={0} differs, why have that when the whole union __u={0} ? gcc 4.9.4 gives a warning when assigning _c[1] like above.
(In reply to Joakim Tjernlund from comment #29) > (In reply to Helmut Jarausch from comment #28) > > With gcc-6.3.0, glibc-2.25 und linux-4.10.0 > > > > I use > > > > union { void _u(){}; typeof(x) __val; char __c[1]={0}; } __u={0}; > > Very close to my last patch, but the __c[1]={0} differs, why have that > when the whole union __u={0} ? > > gcc 4.9.4 gives a warning when assigning _c[1] like above. That's a copy'n paste error. union { void _u(){}; typeof(x) __val; char __c[1]; } __u={0}; is fine.
Wow, I'm really impressed you guys found a working solution. Unfortunately patching the kernel cannot be added to the virtualbox-guest-additions ebuilds. So we either need to wait till upstream found a sloution, or you guys find a solution that does not involve patching non-virtualbox software.
(In reply to Lars Wendler (Polynomial-C) from comment #31) > Wow, I'm really impressed you guys found a working solution. Thanks :) > > Unfortunately patching the kernel cannot be added to the > virtualbox-guest-additions ebuilds. So we either need to wait till upstream > found a sloution, or you guys find a solution that does not involve patching > non-virtualbox software. Kernel folks are so far reluctant to include C++ fixes in private kernel headers. I think gentoo-sources could carry these until a official fix is available but not something I am going push forward. You could add the vbox ebuild part now, it wont hurt anything. Anyone know what Vbox. people are doing? I haven't found anything.
Thanks for making thoses patches ! However... I just began to use gentoo, and I have no idea how to apply them, would it be possible for you to explain how to do that ? Thanks in advance !
(In reply to Joakim Tjernlund from comment #32) > (In reply to Lars Wendler (Polynomial-C) from comment #31) > > Wow, I'm really impressed you guys found a working solution. > > Thanks :) > > > > > Unfortunately patching the kernel cannot be added to the > > virtualbox-guest-additions ebuilds. So we either need to wait till upstream > > found a sloution, or you guys find a solution that does not involve patching > > non-virtualbox software. > > Kernel folks are so far reluctant to include C++ fixes in private kernel > headers. I think gentoo-sources could carry these until a official fix > is available but not something I am going push forward. Looks like akpm has accepted both patches in his tree, lets see if them make it all the way into the kernel. Time to fix the ebuild's soon :) > > You could add the vbox ebuild part now, it wont hurt anything. > > Anyone know what Vbox. people are doing? I haven't found anything.
If it's good enough for akpm, surely it's good enough for a gentoo-sources patch, right? Any chance that could happen?
Created attachment 466462 [details, diff] bitops typ fixes
Created attachment 466464 [details, diff] void * cast with uintptr_t
Created attachment 466466 [details, diff] Mock up a __builtin_types_compatible_p for C++
With the last 3 patches, all Vbox builds without fixes to the ebuilds. Unsure if all these fixes are correct though, please comment on them.
One thing more I have noted, Vbox modules builds against the RUNNING kernels headers, not the one you have eselected This causes mysterious bugs etc. This problem has been there for a long time though.
(In reply to Joakim Tjernlund from comment #39) > With the last 3 patches, all Vbox builds without fixes to the ebuilds. > Unsure if all these fixes are correct though, please comment on them. With your patches I get: fs/ext4/balloc.c: In function ‘ext4_init_block_bitmap’: fs/ext4/balloc.c:215:21: error: passing argument 2 of ‘__set_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] ext4_set_bit(bit, bh->b_data); ^ In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:71:60: note: expected ‘long unsigned int *’ but argument is of type ‘char *’ static inline void __set_bit_le(int nr, unsigned long *addr) ^ fs/ext4/balloc.c:225:58: error: passing argument 2 of ‘__set_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:71:60: note: expected ‘long unsigned int *’ but argument is of type ‘char *’ static inline void __set_bit_le(int nr, unsigned long *addr) ^ fs/ext4/balloc.c:229:58: error: passing argument 2 of ‘__set_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:71:60: note: expected ‘long unsigned int *’ but argument is of type ‘char *’ static inline void __set_bit_le(int nr, unsigned long *addr) ^ fs/ext4/balloc.c:235:59: error: passing argument 2 of ‘__set_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:71:60: note: expected ‘long unsigned int *’ but argument is of type ‘char *’ static inline void __set_bit_le(int nr, unsigned long *addr) ^ fs/ext4/balloc.c: In function ‘ext4_valid_block_bitmap’: fs/ext4/balloc.c:342:56: error: passing argument 2 of ‘test_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:56:59: note: expected ‘const long unsigned int *’ but argument is of type ‘char *’ static inline int test_bit_le(int nr, const unsigned long *addr) ^ fs/ext4/balloc.c:349:56: error: passing argument 2 of ‘test_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:56:59: note: expected ‘const long unsigned int *’ but argument is of type ‘char *’ static inline int test_bit_le(int nr, const unsigned long *addr) ^ fs/ext4/balloc.c:356:40: error: passing argument 1 of ‘find_next_zero_bit_le’ from incompatible pointer type [-Werror=incompatible-pointer-types] next_zero_bit = ext4_find_next_zero_bit(bh->b_data, ^ In file included from ./arch/x86/include/asm/bitops.h:504:0, from ./include/linux/bitops.h:36, from ./include/linux/kernel.h:10, from ./include/linux/list.h:8, from ./include/linux/preempt.h:10, from ./include/linux/spinlock.h:50, from ./include/linux/seqlock.h:35, from ./include/linux/time.h:5, from fs/ext4/balloc.c:14: ./include/asm-generic/bitops/le.h:11:69: note: expected ‘const long unsigned int *’ but argument is of type ‘char *’ static inline unsigned long find_next_zero_bit_le(const unsigned long *addr, ^ cc1: some warnings being treated as errors make[2]: *** [scripts/Makefile.build:292: fs/ext4/balloc.o] Error 1 make[1]: *** [scripts/Makefile.build:543: fs/ext4] Error 2 make: *** [Makefile:988: fs] Error 2
(In reply to Paolo Pedroni from comment #41) > (In reply to Joakim Tjernlund from comment #39) > > With the last 3 patches, all Vbox builds without fixes to the ebuilds. > > Unsure if all these fixes are correct though, please comment on them. > > With your patches I get: > > fs/ext4/balloc.c: In function ‘ext4_init_block_bitmap’: > fs/ext4/balloc.c:215:21: error: passing argument 2 of ‘__set_bit_le’ from > incompatible pointer type [-Werror=incompatible-pointer-types] > ext4_set_bit(bit, bh->b_data); > ^ > In file included from ./arch/x86/include/asm/bitops.h:504:0, > from ./include/linux/bitops.h:36, > from ./include/linux/kernel.h:10, > from ./include/linux/list.h:8, > from ./include/linux/preempt.h:10, > from ./include/linux/spinlock.h:50, > from ./include/linux/seqlock.h:35, > from ./include/linux/time.h:5, > from fs/ext4/balloc.c:14: > ./include/asm-generic/bitops/le.h:71:60: note: expected ‘long unsigned int > *’ but argument is of type ‘char *’ > static inline void __set_bit_le(int nr, unsigned long *addr) > ^ Yes, now that these functions actually have a type, parst of kernel code will complain. I guessing these should be fixed to user the proper type but for now you will have to live with these warnings.
(In reply to Joakim Tjernlund from comment #42) > (In reply to Paolo Pedroni from comment #41) > > (In reply to Joakim Tjernlund from comment #39) > > fs/ext4/balloc.c: In function ‘ext4_init_block_bitmap’: > > fs/ext4/balloc.c:215:21: error: passing argument 2 of ‘__set_bit_le’ from > > incompatible pointer type [-Werror=incompatible-pointer-types] > > ext4_set_bit(bit, bh->b_data); They are not warnings: it's an error. Kernel compilation is halted.
(In reply to Paolo Pedroni from comment #43) > (In reply to Joakim Tjernlund from comment #42) > > (In reply to Paolo Pedroni from comment #41) > > > (In reply to Joakim Tjernlund from comment #39) > > > fs/ext4/balloc.c: In function ‘ext4_init_block_bitmap’: > > > fs/ext4/balloc.c:215:21: error: passing argument 2 of ‘__set_bit_le’ from > > > incompatible pointer type [-Werror=incompatible-pointer-types] > > > ext4_set_bit(bit, bh->b_data); > > > They are not warnings: it's an error. Kernel compilation is halted. No, they are warnings turned into errors by passing Werror to gcc. I guess you have a kernel config that does not allow warnings, you can turn that strictness off.
virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and virtualbox-guest-additions-5.1.12 was removed
(In reply to Joakim Tjernlund from comment #44) > No, they are warnings turned into errors by passing Werror to gcc. > I guess you have a kernel config that does not allow warnings, you can > turn that strictness off. Where? I've checked my kernel configuration and nothing stands out. Do you have any idea?
(In reply to Stéphane BARBARAY from comment #45) > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > virtualbox-guest-additions-5.1.12 was removed Was this after you applied the patches to the kernel? Thanks
(In reply to Randy Tupas from comment #47) > (In reply to Stéphane BARBARAY from comment #45) > > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > > virtualbox-guest-additions-5.1.12 was removed > > Was this after you applied the patches to the kernel? > > Thanks No patches applied
(In reply to Stéphane BARBARAY from comment #48) > (In reply to Randy Tupas from comment #47) > > (In reply to Stéphane BARBARAY from comment #45) > > > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > > > virtualbox-guest-additions-5.1.12 was removed > > > > Was this after you applied the patches to the kernel? > > > > Thanks > > No patches applied ...but xf86-video-virtualbox-5.1.16 still does not compile Btw, as Joakim suggested, it would be really useful to build against the eselected kernel instead of the running one (that's forcing us to boot with a non working guest-additions first before being able to compile)...
(In reply to Stéphane BARBARAY from comment #49) > (In reply to Stéphane BARBARAY from comment #48) > > (In reply to Randy Tupas from comment #47) > > > (In reply to Stéphane BARBARAY from comment #45) > > > > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > > > > virtualbox-guest-additions-5.1.12 was removed > > > > > > Was this after you applied the patches to the kernel? > > > > > > Thanks > > > > No patches applied > > ...but xf86-video-virtualbox-5.1.16 still does not compile > > Btw, as Joakim suggested, it would be really useful to build against the > eselected kernel instead of the running one (that's forcing us to boot with > a non working guest-additions first before being able to compile)... Thanks for the info. I can't build either package :-(
(In reply to Stéphane BARBARAY from comment #48) > > Was this after you applied the patches to the kernel? > > > > Thanks > > No patches applied I can confirm this...
(In reply to Stéphane BARBARAY from comment #49) > ...but xf86-video-virtualbox-5.1.16 still does not compile ...and this :((
(In reply to Stéphane BARBARAY from comment #49) > (In reply to Stéphane BARBARAY from comment #48) > > (In reply to Randy Tupas from comment #47) > > > (In reply to Stéphane BARBARAY from comment #45) > > > > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > > > > virtualbox-guest-additions-5.1.12 was removed > > > > > > Was this after you applied the patches to the kernel? > > > > > > Thanks > > > > No patches applied > > ...but xf86-video-virtualbox-5.1.16 still does not compile > > Btw, as Joakim suggested, it would be really useful to build against the > eselected kernel instead of the running one (that's forcing us to boot with > a non working guest-additions first before being able to compile)... I noted that xf86-video-virtualbox uses --with-linux="${KV_OUT_DIR}" and I wonder if KV_OUT_DIR is defined unless "linux-info" is inherited? Any care to test that theory?
(In reply to Joakim Tjernlund from comment #53) > (In reply to Stéphane BARBARAY from comment #49) > > (In reply to Stéphane BARBARAY from comment #48) > > > (In reply to Randy Tupas from comment #47) > > > > (In reply to Stéphane BARBARAY from comment #45) > > > > > virtualbox-guest-additions-5.1.16 compiled fine with kernel 4.9 and > > > > > virtualbox-guest-additions-5.1.12 was removed > > > > > > > > Was this after you applied the patches to the kernel? > > > > > > > > Thanks > > > > > > No patches applied > > > > ...but xf86-video-virtualbox-5.1.16 still does not compile > > > > Btw, as Joakim suggested, it would be really useful to build against the > > eselected kernel instead of the running one (that's forcing us to boot with > > a non working guest-additions first before being able to compile)... > > I noted that xf86-video-virtualbox uses --with-linux="${KV_OUT_DIR}" and I > wonder > if KV_OUT_DIR is defined unless "linux-info" is inherited? > > Any care to test that theory? Did a quick test and KV_OUT_DIR is undefined. Turns out that you have not only to inherit linux-info, one must also call linux-info_pkg_setup as can be seen in linx-info.eclass: # Before using any of the config-handling functions in this eclass, you must # ensure that one of the following functions has been called (in order of # preference), otherwise you will get bugs like #364041): # linux-info_pkg_setup # linux-info_get_any_version # get_version # get_running_version I suspect this is a problem in the the other Vbox ebuilds too. To lazy to wip up a patches though, anyone feel free :)
Should no longer be an issue.
