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>
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5618de75aec49009489efb560a89e014fd060524 commit 5618de75aec49009489efb560a89e014fd060524 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-02-05 19:29:36 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-02-10 10:47:23 +0000 llvm-r1.eclass: Initial version Bug: https://bugs.gentoo.org/923228 Bug: https://bugs.gentoo.org/880671 Closes: https://bugs.gentoo.org/821955 Closes: https://bugs.gentoo.org/919150 Signed-off-by: Michał Górny <mgorny@gentoo.org> eclass/llvm-r1.eclass | 250 ++++++++++++++++++++++++++++++++++++++++++++++++ eclass/tests/llvm-r1.sh | 151 +++++++++++++++++++++++++++++ 2 files changed, 401 insertions(+)
building media-gfx/blender-4.0.2 with USE=osl fails with error: Cycles OSL requires WITH_LLVM, the library may not have been found. Configure LLVM or disable WITH_CYCLES_OSL is this related to current issue?
This should be handled by.. commit 175d65e779e69e5702ca52cb3af973a2fa0b0e62 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Zander <negril.nx+gentoo@gmail.com> Date: Thu Mar 28 23:08:25 2024 +0100 media-gfx/blender: add 4.0.2-r1, cleanup hopefully fixed osl build re-added hip flag in 4.0.2-r1 hide test code in release versions Bug: https://bugs.gentoo.org/693200 Closes: https://bugs.gentoo.org/925534 Closes: https://bugs.gentoo.org/927281 Closes: https://bugs.gentoo.org/927715 Closes: https://bugs.gentoo.org/927835 Closes: https://bugs.gentoo.org/927931 Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/35973 Signed-off-by: Sam James <sam@gentoo.org> ... which introduces use of llvm-r1.eclass.
