Compilation of GHOST_XrGraphicsBinding.cc fails with "invalid conversion" error #111820
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#111820
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Artix Linux
Graphics card: Radeon RX470
Blender Version
Broken: 3.6.2
Worked: 3.6.2
Compiling Blender using Arch Linux's build files always worked for me previously but now fails with the following:
I can compile successfully with "WITH_GHOST_SDL=ON." This began happening after Arch moved from LLVM15 to LLVM 16. I seem to be the only person to have ever encountered this error, so I presume it's something idiosyncratic about my box, but I'm clueless where even to begin looking. I've experimented with compiling with both LLVM15 and LLVM16. I use X11 and not Wayland. The version of Blender that I'm attempting to compile has not changed.
I was able to reproduce this. I have a Dockerfile where I build Blender and I ran into this. The containers I use are Arch-based so that checks out as well. I was able to get around the error by using
WITH_GHOST_SDL=ONlike you mentioned.GHOST_XrGraphicsBinding.ccis c plus plus, it probably needs a type casting there.If nothing else I guess I'll make a patch later on.
Probably because the compiler gets more strict.
I'd be happy to try testing any such patch, if that'd help.
@Frank-Carlyle-McLaughlin Could you test: #111915?
That would be much appreciated ❤️
I'd happily test it as well.
Unfortunately, that patch didn't help me. I tested Arch's official PKGBUILD (which uses LLVM 15) with just that one change. I also tested a few different personal configurations using LLVM 16 (and OSL disabled, but compilation never got that far). I get largely the same result no matter what:
For what little it's probably worth, I did a bit of poking, and it seems that OpenXR recently made a change involving "eglGetProcAddress" in version 1.0.29 (see
f66902f299). I can't figure out a way to link directly to it, but it looks like they added the lineand changed an instance of
PFNEGLGETPROCADDRESSPROCtoPFN_xrEglGetProcAddressMNDXin file "specification/registry/xr.xml", if that's any help at all.Interesting, here on my installation the header still shows as
PFNEGLGETPROCADDRESSPROC. I guess maybe blender compilation libs needs an update (Or not, to be compatible with their centos machine...). For now I think if these libs doesn't officially support llvm16 (or like, reporting this issue to OpenXR), we probably will be stuck with this.There seems to be an instance of that, too. I don't claim to understand any of it! That's just what I got from downloading the sources for both 1.0.28 and 1.0.29, grepping for "eglgetprocaddress," and comparing the results. I was hoping maybe what they did would provide a useful clue -- possibly the "typedef void" bit in the added line.
Yup, unfortunately seems like this isn't enough :/
On a hunch, I tried compiling without OpenXR using my own LLVM 16 build (i.e.,
-DWITH_XR_OPENXR=OFF), and it succeeded! Due to #111834, I also compiled it without OpenShadingLanguage (i.e.,-DWITH_CYCLES_OSL=OFF), and I encountered no ensuing weirdness with using Cycles otherwise. I then tested a vanilla (i.e., without your patch) build of Arch's official PKGBUILD but with OpenXR downgraded to version 1.0.28 in the compilation chroot, and that also succeeded! Due again to #111834, I had to use the trick of specifying the driver and library path for the prior LLVM 15 version of mesa, but even with OpenXR 1.0.29 actually installed, it otherwise opened and ran fine (although I have no way to test any of OpenXR's special functions, because I have no VR or AR anything). So it appears that there's some kind of incompatibility with the current version of OpenXR (which claims to have made the abovementioned change "to avoid compiler errors"), and the patch doesn't make any difference one way or the other. Hope that helps.@Frank-Carlyle-McLaughlin Thanks for mentioning #111834, I thought
WITH_GHOST_SDL=ONwas the reason my build was crashing, now I know that it's because of OSL. I'll keep an eye on that report as well.@a13xie @Frank-Carlyle-McLaughlin could you guys test again?
I regret to report that compilation still did not succeed, although the error does look a little bit different now:
I tested this both with Arch's PKGBUILD with only that patch added, and with my own customized build (i.e., with LLVM 16 and no OSL), and got the same thing either way.
For the record, and just to be sure I didn't goof up the implementation, I created and applied the following patch:
Yup, not quite there yet
@Frank-Carlyle-McLaughlin btw, you can get the patch directly from Gitea.
Well then looks like
PFN_xrEglGetProcAddressMNDXis still incorrect then :/Try changing
static_casttoreinterpret_cast.@a13xie thanks for the tip! I did not know that.
@ChengduLittleA @brecht Tentative success changing
static_casttoreinterpret_cast! Arch's PKGBUILD with the patch, as modified with that one change, compiles! I won't be able to test how well it actually runs until this evening, and as noted I don't have the ability to test any kind of VR or AR functionality at all, but the ensuing build does at least launch. I intend to test my own LLVM 16 build this evening, too.My apologies for the delay. I have now tested the patch, substituting
reinterpret_castforstatic_castwith both Arch's build (LLVM 15) and with my own Arch-derived build (LLVM 16), with OpenXR enabled for both, and compilation succeeds for both! Blender appears to work properly afterwards, although, as noted, I lack any way to test VR or AR functionality, so I can't guarantee there isn't something still subtly broken under the hood. Nevertheless, the patch, as modified, solves my compilation problem perfectly. Thank you!