FreeBSD 12.2 amd64 with all updated ports. ... In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib/server_bufferobject.cpp:11: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib/server.h:11: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/cr_glstate.h:46: /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/out/freebsd.amd64/release/obj/VBoxOGLgen/spu_dispatch_table.h:913:58: error: unknown type name 'VBoxGLhandleARB'; did you mean 'GLhandleARB'? typedef void (SPU_APIENTRY *GetAttachedObjectsARBFunc_t)(VBoxGLhandleARB, GLsizei, GLsizei *, VBoxGLhandleARB *); ^~~~~~~~~~~~~~~ GLhandleARB /usr/local/include/GL/glext.h:4082:22: note: 'GLhandleARB' declared here typedef unsigned int GLhandleARB; In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib/server_getmap.cpp:7: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/cr_spu.h:16: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/out/freebsd.amd64/release/obj/VBoxOGLgen/spu_dispatch_table.h:18: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/chromium.h:112: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/cr_glext.h:24: /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/GL/glext.h:3739:3: error: "GL_ARB_shader_objects should NOT be defined here!!" # error "GL_ARB_shader_objects should NOT be defined here!!" ^ ...
kBuild: Compiling VBoxOGLcrserverlib - /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib/server_getmap.cpp In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib/server_clear.cpp:7: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/cr_spu.h:16: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/out/freebsd.amd64/release/obj/VBoxOGLgen/spu_dispatch_table.h:18: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/chromium.h:112: In file included from /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/cr_glext.h:24: /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include/GL/glext.h:55:9: warning: 'GL_GLEXT_VERSION' macro redefined [-Wmacro-redefined] #define GL_GLEXT_VERSION 41 ^ /usr/local/include/GL/glext.h:54:9: note: previous definition is here #define GL_GLEXT_VERSION 20190911 ^
I am seeing the same issue and it was also reported on the mail list. You may change this to "Affects some people" at the least. I suspect "Many" is correct.
I'm seeing this on 11.4-STABLE as well with all packages up to date but this one. FreeBSD xxxx 11.4-STABLE FreeBSD 11.4-STABLE #2 r366655: Mon Oct 12 18:01:20 MDT 2020 xxxx
I can confirm this issue. I'm getting the same error in poudriere. Looks like this is fallout from r552109, which updated mesa ports to 20.2.0. If that's the case it will affect all OS versions using the latest ports tree branch I'm adding manu@ to the CC list so he is informed.
Created attachment 218732 [details] Full poudriere build log I'm adding a full poudriere build log of the failed build in case it could be useful.
GL_GLEXT_VERSION was already defined in mesa-19 (it's mandatory to have it since it's defined by the Khronos implementation). I don't know why virtualbox have it's own copy of the GL header (and why they differs)
(In reply to Emmanuel Vadot from comment #6) I don't understand why they have a (bad) cosy of GL source code embedded in virtualbox. One idea (which I could try doing later) is looking at virtualbox source code history to get a clue why they have that. One quick solution could be to add an option to the port to disable GL support in virtualbox, but not a very good one. One more thing to try could be to simply replace the glext.h file in virtualbox with a newer one from mesa-libs.
Problem in include order: /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/HostServices/SharedOpenGL/crserverlib /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/include/VBox/Graphics /usr/local/include /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.44/src/VBox/GuestHost/OpenGL/include /usr/local/include - must be after /src/VBox/GuestHost/OpenGL/include. /usr/local/include is set via TEMPLATE_VBOXR3EXE_INCS. VBOX_GRAPHICS_INCS = $(PATH_ROOT)/include/VBox/Graphics VBOX_PATH_CROGL_INCLUDE = $(PATH_ROOT)/src/VBox/GuestHost/OpenGL/include This hack help with OpenGL, but build fail later. @${REINPLACE_CMD} \ -e 's|TEMPLATE_VBOXR3EXE_INCS|TEMPLATE_VBOXR3EXE___INCS|' \ -e 's|/GuestHost/OpenGL/include|/GuestHost/OpenGL/include /usr/local/include|' \ ${WRKSRC}/Config.kmk @${REINPLACE_CMD} \ -e 's|$$(VBOX_GRAPHICS_INCS)|$$(VBOX_GRAPHICS_INCS) /usr/local/include|' \ ${WRKSRC}/src/VBox/Devices/Makefile.kmk I do not understand kBuild template mess, at least today.
(In reply to rozhuk.im from comment #8) Virtualbox included glext.h file has a comment: /* Header file version number, required by OpenGL ABI for Linux */ /* glext.h last updated 2008/08/10 */ /* Current version at http://www.opengl.org/registry/ */ SO I tought I could follow that link and ended up here: https://www.khronos.org/registry/OpenGL/index_gl.php#headers I know nothing about OpenGL development, but it looks like they are providing a "generic" include file to be embedded in projects. I'm now testing with a glext.h file downloaded from there. Willl followup here with results once poudriere is done rebuilding things.
(In reply to Guido Falsi from comment #9) Using the glext.h file from https://www.khronos.org/registry/OpenGL/index_gl.php#headers causes a failure with slightly different errors but anyway is not working.
This hack work for me: @${REINPLACE_CMD} \ -e 's|$$(VBOX_GRAPHICS_INCS)|$$(VBOX_PATH_CROGL_INCLUDE) $$(VBOX_GRAPHICS_INCS)|g' \ ${WRKSRC}/src/VBox/HostServices/SharedOpenGL/Makefile.kmk This works too and looks like correct change of includes order by template system: @${REINPLACE_CMD} \ -e 's|TEMPLATE_VBOXCROGLR3HOSTDLL_EXTENDS_BY.*|TEMPLATE_VBOXCROGLR3HOSTDLL_EXTENDS_BY = appending|g' \ ${WRKSRC}/Config.kmk
(In reply to rozhuk.im from comment #11) I would like to confirm: the last patch is working for me: $ uname -srm FreeBSD 12.2-RC2 amd64
(In reply to rozhuk.im from comment #11) Could you provide this as a patch against the port from svn head?
Created attachment 218769 [details] Patch to deal with updated mesa This patch applies and configures cleanly. Due to a hardware issue (fan) with my system, I can't do a build at this time. I can only say that it gets much further than it used to. Hopefully, others will report success/failure.
(In reply to rkoberman from comment #14) I'm going to test this in poudriere and report back. It could take some time though, since my build machine is already busy in another bog build.
Created attachment 218771 [details] patch Change include order to place /usr/local/include after src/VBox/GuestHost/OpenGL/include, fix build issue with glext.h.
Two patches that do the same things in different ways. The port is a mix of patches to the sources and sed -i fixes. I like the one rozhuk.im submitted that patches the patch file better than mine, but I guess it's up to the maintainer to pick whichever she/he prefers.
Fix by rozhuk.im from comment #16 works for me.
(In reply to rkoberman from comment #14) Comment 14 rkoberman's patch built for me too. Didn't do more than a dead or alive for running.
(In reply to rkoberman from comment #14) > I can only say that it gets much further than it used to. No, it do not enough :) Regexp do 4 replaces in src/VBox/HostServices/SharedOpenGL/Makefile.kmk, same things affected after template changes. But template changes also affects src/VBox/GuestHost/OpenGL/Makefile.kmk. grep VBOXCROGLR3HOSTDLL: Config.kmk:TEMPLATE_VBOXCROGLR3HOSTLIB_EXTENDS = VBOXCROGLR3HOSTDLL src/VBox/HostServices/SharedOpenGL/Makefile.kmk:VBoxSharedCrOpenGL_TEMPLATE = VBOXCROGLR3HOSTDLL grep VBOXCROGLR3HOSTLIB: src/VBox/GuestHost/OpenGL/Makefile.kmk:VBoxOGLhostcrutil_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/GuestHost/OpenGL/Makefile.kmk:VBoxOGLhostcrpacker_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/GuestHost/OpenGL/Makefile.kmk:VBoxOGLhostspuload_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/GuestHost/OpenGL/Makefile.kmk:VBoxOGLhostcrstate_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/GuestHost/OpenGL/Makefile.kmk:VBoxOGLhosterrorspu_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/HostServices/SharedOpenGL/Makefile.kmk:VBoxOGLcrserverlib_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/HostServices/SharedOpenGL/Makefile.kmk:VBoxOGLcrunpacker_TEMPLATE = VBOXCROGLR3HOSTLIB src/VBox/HostServices/SharedOpenGL/Makefile.kmk:VBoxOGLrenderspu_TEMPLATE = VBOXCROGLR3HOSTLIB Probably src/VBox/GuestHost/OpenGL/Makefile.kmk used in guest addons or other parts but not used for this port.
A commit references this bug: Author: madpilot Date: Sat Oct 17 13:29:42 UTC 2020 New revision: 552571 URL: https://svnweb.freebsd.org/changeset/ports/552571 Log: Fix emulators/virtualbox-ose build after r552109. VirtualBox embeds an outdated version of glext.h, causing it to fail to build due to symbols being redefined incorrectly. Import patch which forces virtualbox to append it's own include paths, thus not "obscuring" the system provided OpenGL include file. PR: 250315 Submitted by: rozhuk.im@gmail.com Approved by: portmgr (fixit blanket) Changes: head/emulators/virtualbox-ose/files/patch-Config.kmk
After some testing I committed rozhuk.im@gmail.com patch. I'll leave to him as submitter to close this bug report if he agrees this fixes the issue, otherwise to describe what prevents the issue from being accounted as closed. Thanks!
It seems that a similar issue still arises in emulators/virtualbox-ose-additions. -- Martin
(In reply to Martin Birgmeier from comment #23) Before committing the patch from this bug I did test emulators/virtualbox-ose-additions and it built fine. Could you attach a full log of the failing build? Please note that emulators/virtualbox-ose-additions usses the ssame patches from emulators/virtualbox-ose, so the patch I committed there affect additions too.
Created attachment 218941 [details] failed build of virtualbox-ose-additions Please find the build log attached. ports are at r552852. -- Martin
(In reply to Martin Birgmeier from comment #25) The error is not the same, and while it is still is in the OpenGL area is not the same. I have tried rebuilding in poudriere and could not reproduce this. I'd suggest you try force reinstalling mesa ports. This is just a guess, it could be something else installed on the system interfering. I'm trying to understand, maybe this is a local issue or maybe a rare case that requires addressing. BTW building things on live systems like portmaster does is prone to errors caused by specific conditions in the building machine. The port could be working fine like it does in poudriere and the cause some "misalignment" in the local machine. BTW you're using the latest ports tree, correct?
(In reply to Guido Falsi from comment #26) Sorry, not only mesa ports but also the virtualbox-ose port itself.
(In reply to Martin Birgmeier from comment #25) There is several glxext.h files: include/VBox/HostServices/glxext.h src/VBox/Devices/Graphics/vmsvga_glext/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.10.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.12.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.14.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.17.1/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.0.1/glxext.h src/VBox/Additions/x11/x11include/mesa-11.0.7/GL/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.7.7/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.5.3/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.9.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.3.0.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.16.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.18.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.11.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.13.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.15.0/glxext.h src/VBox/Additions/x11/x11include/mesa-7.2/GL/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.6.5/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.4.2/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.8.0/glxext.h src/VBox/Additions/x11/x11include/xorg-server-1.1.0/glxext.h And no attempt to include during to build src/VBox/Additions/common/crOpenGL/glx.c. Probably because: post-patch-OPENGL-on: @${ECHO_CMD} 'VBOX_USE_SYSTEM_GL_HEADERS = 1' >> ${WRKSRC}/LocalConfig.kmk Removing this does not help, it try to build libs that system already have -fail in onother place. This is dead end: manipulations with system headers / include order will not help. I look into src/VBox/Additions/common/crOpenGL/dri_glx.h and found: /** * Set this to 1 if you want to build stub functions for the * GL_SGIX_pbuffer and GLX_SGIX_fbconfig extensions. * This used to be disabled, due to "messy compilation issues", * according to the earlier comment; but they're needed just * to resolve symbols for OpenInventor applications, and I * haven't found any reference to exactly what the "messy compilation * issues" are, so I'm re-enabling the code by default. */ #define GLX_EXTRAS 1 I remove it using: @${REINPLACE_CMD} \ -e 's|#define GLX_EXTRAS 1||g' \ ${WRKSRC}/src/VBox/Additions/common/crOpenGL/dri_glx.h \ ${WRKSRC}/src/VBox/Additions/common/crOpenGL/glx_proto.h And build OK.
Created attachment 218949 [details] patch for virtualbox-ose-additions with OpenGL
I did not check that it work - I do not use OpenGL in guests. It allow build virtualbox-ose-additions with OpenGL without errors. Hope some one test it and report here. (sorry for noice)
Hi rozhuk.im, I tried your patch, but the build still fails: In file included from /usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/src/VBox/Additions/common/crOpenGL/glx.c:32: /usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/src/VBox/Additions/common/crOpenGL/dri_glx.h:114:35: error: conflicting types for 'glXQueryGLXPbufferSGIX' extern DECLEXPORT(int) VBOXGLXTAG(glXQueryGLXPbufferSGIX) ^ /usr/local/include/GL/glxext.h:861:6: note: previous declaration is here void glXQueryGLXPbufferSGIX (Display *dpy, GLXPbufferSGIX pbuf, int attr... ^ kBuild: Generating python - /usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/out/freebsd.amd64/release/obj/VBoxOGLgen/freebsd_exports.c kBuild: Compiling VBoxEGL - /usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/src/VBox/Additions/common/crOpenGL/egl.c /usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/src/VBox/Additions/common/crOpenGL/glx.c:766:28: error: conflicting types for 'glXQueryGLXPbufferSGIX' DECLEXPORT(int) VBOXGLXTAG(glXQueryGLXPbufferSGIX)(Display *dpy, GLXPbuf... ^ /usr/local/include/GL/glxext.h:861:6: note: previous declaration is here void glXQueryGLXPbufferSGIX (Display *dpy, GLXPbufferSGIX pbuf, int attr... ^ 2 errors generated. kmk: *** [/usr/tmp/a/SRC/FreeBSD-ports/head/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.44/out/freebsd.amd64/release/obj/VBoxOGL/glx.o] Error 1 -- Martin
Hi Guido, Yes, my ports tree is at latest. Also, it is clear that using portmaster means that there can be interference with other ports. One question: I patched virtualbox-ose{,-additions} to allow simultaneous installation of both (commented out the conflict lines) because on the build VM I am building for both vbox servers as well as clients. This has always been working so far. Could it be the reason for this new breakage? -- Martin
(In reply to Martin Birgmeier from comment #32) cd emulators/virtualbox-ose-additions make clean make patch check files: ${WRKSRC}/src/VBox/Additions/common/crOpenGL/dri_glx.h and ${WRKSRC}/src/VBox/Additions/common/crOpenGL/glx_proto.h ensure that there is no: #define GLX_EXTRAS 1
Hi rozhuk.im, You are perfectly right, I misapplied the patch. In fact, the port now builds with your patch. Thank you for your "noise" which should rather read "help"! -- Martin
(In reply to Martin Birgmeier from comment #32) Installing those two together could be causing problems, but it's now evident I misunderstood your issue. rozhuk.im, thanks for this further patch. Please give me some time for testing.
A commit references this bug: Author: madpilot Date: Sat Oct 24 10:22:25 UTC 2020 New revision: 553175 URL: https://svnweb.freebsd.org/changeset/ports/553175 Log: Apply fix to emulators/virtualbox-ose-additions to allow building with OPENGL option on after ports r552109. PR: 250315 Submitted by: rozhuk.im@gmail.com Approved by: portmgr (fixit blanket) Changes: head/emulators/virtualbox-ose-additions/Makefile
(In reply to commit-hook from comment #36) This fix has been reported to cause undefined symbol issues: https://lists.freebsd.org/pipermail/freebsd-x11/2020-October/027007.html Disabling extensions outright seems to be problematic.
Created attachment 219058 [details] virtualbox-ose-additions patch New patch to try a fix for additions which will work at runtime. This patch aligns the GL includes embedded in virtualbox with libraries installed by the mesa ports. Some functions had their prototypes modified. Especially glXQueryGLXPbufferSGIX had it's return type changed from int to void. It's not problematic since the one included in virtualbox-ose is a stub always returning "0" after dumping an error message.
A commit references this bug: Author: madpilot Date: Tue Oct 27 09:10:57 UTC 2020 New revision: 553427 URL: https://svnweb.freebsd.org/changeset/ports/553427 Log: Fix patch to virtualbox-ose-additions OpenGL ssupport to actually work at runtime as much as possible. The OpenGL bits in VirtualBox 5 are an old implementation that does not play too well with what wee have in the tree now. Thesse patches simply change the funzionn prototypess in VirtualBox to match the ones from mesa so it caan compile and interface as much as possible with it. Thanks to Ronald Klop <ronald-lists@klop.ws> for testing. PR: 250315 Submitted by: rozhuk.im@gmail.com Approved by: portmgr (fixit blanket) Changes: head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_dri__glx.h head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_fakedri__drv.h head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx.c head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx__c__exports.c head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_common_crOpenGL_glx__proto.h head/emulators/virtualbox-ose-additions/Makefile
I'm closing this as fixed since with the last patch things are working even though some warning messages remain with OpenGL support. I don't think anything much better can be done without major changes to the virtualbox ports. Thanks for the help to all.