Created attachment 830243 [details] output of emerge --info I wanted to boot up Blender again, only to find out that it crashes on startup. In Blender 3.1 (the current amd64 stable version as of writing), it dumps a backtrace to /tmp/blender.crash.txt which can be found below. For some reason, Blender 3.3 does not report a stacktrace properly, but I was able to glean it from GDB. Taking a look at the stacktrace, it's stepping between LLVM 14 and 15 and then the DRI driver for my radeonsi is included somewhere. I'll probably compile it with debug symbols soon to see if there's anything useful there. At first, I thought it was mesa bug #6976 ([Bisected][RadeonSI] Blender crashes on startup) but this was fixed 3 months ago, and I have mesa 22.2.3 installed. This is confirmed by the fact that when downloading the official Blender Linux build, it works just fine! LLVM 15 is at 15.04 LLVM 14 is at 14.06-r2 Oh yeah, and I also attached the blender 3.3 build log, but I haven't tried to glean anything from it yet.
Created attachment 830245 [details] blender 3.3 backtrace
Created attachment 830247 [details] blender 3.1.2 backtrace
Created attachment 830249 [details] blender-3.3-build-log.txt.xz
Created attachment 830251 [details] equery u blender output
It's mixing LLVM 14 and LLVM 15, yeah :(
Sadly I can't really do anything about this. I've filed a ticket about this last year here: https://bugs.gentoo.org/821955 At one point I was thinking about doing a manual ldd in the install phase to see if multiple llvm versions were linked in and error out if that was the case. However this does not catch the mesa llvm version. In addition to that, one could update mesa and the llvm version after the the package has been installed and get crashes that way. So I'm starting to think that static linking is the only way out of this. (This is what the official Blender build do)
You should be able to work around this by unmasking a newer version of osl. It will be built with llvm 15.
Thank you, I had a suspicion that Blender was statically linking LLVM (it explains why their binaries are like 250+ mb!) I thought I had unmasked osl, but I’ll check again when I can get back to my computer.
Yes, using osl ~amd64 and then recompiling both blender versions fixed it. Thank you! For some reason, I can only mark this as "RESOLVED" (which isn't really the right option, I thought there was more?), I'll leave that up to your discretion :-)
I think we can leave it open in case someone else with the same issue ends up here.
It's happening now also with LLVM-15 vs. LLVM-16 (~amd64). As before, blender with USE=-osl fixes it for me.
Can confirm with LLVM 15 and 16 (~amd64). Using "-osl" makes it finally start, but rendering a benchmark scene produces a segmentation fault with the usual backtrace #1 0x... in () at /usr/lib/llvm/16/lib64/libLLVM-16.so
(In reply to Lorenzo Bertini from comment #12) > Can confirm with LLVM 15 and 16 (~amd64). Using "-osl" makes it finally > start, but rendering a benchmark scene produces a segmentation fault with > the usual backtrace > #1 0x... in () at /usr/lib/llvm/16/lib64/libLLVM-16.so Could you perhaps build Blender with debug flags so we can see where it is crashing?
Created attachment 865610 [details] blender 3.3 llvm 15+16 backtrace This still happens with the current gentoo repository. Blender appears to use both LLVM 15 and LLVM 16 at the same time, and segmentation faults on startup.
I have another Gentoo system which does not have LLVM 16 installed yet, and the segmentation fault does not reproduce there. It seems the best/only workaround for this is: cat <<EOF> /etc/portage/package.mask/llvm >=sys-devel/llvm-16 >=sys-devel/clang-16 >=sys-devel/llvmgold-16 >=sys-devel/llvm-common-16 EOF emerge --unmerge '>=sys-devel/llvm-16' '>=sys-devel/clang-16' '>sys-devel/llvmgold-16' revdep-rebuild # rebuilds mesa in particular emerge --depclean After doing this, blender starts without a Segmentation Fault, and does not crash while rendering. It would be convenient if the blender and/or osl ebuild were able to entirely prevent the installation of llvm-16 until osl catches up.
commit d6af608ad3b3519f7cbd4e4158afbb7c979d887c Author: Sebastian Parborg <darkdefende@gmail.com> Date: Sun Jul 2 23:06:55 2023 +0200 media-gfx/blender: Disable OSL support per default Because llvm 16 is now marked stable, there is a very high chance of users having Blender sefault on startup because of missmatched llvm libraries. Signed-off-by: Sebastian Parborg <darkdefende@gmail.com> Signed-off-by: Sam James <sam@gentoo.org>
