The tbb_2021_13 addition looks fine to me. The nixpkgs-vet check about that can be ignored I think.

EDIT: I don't have much advice about Blender but it's possible the segfaults might be due to TBB. I know that on MacOS there were issues with certain TBB versions when we were testing the BLAKE3 packages (that didn't exist with the homebrew TBB, so could have been related to our patches). I didn't see any issues on Linux though but still. If you're able to try a different version of TBB than tbb_2021_13 that might be something to investigate.

@silvanshade Blender seems to require 2021.13.0 now, I tried overriding all the deps, but maybe I missed some. Compiling everything takes 20mins, so It's a bit of a headache, and I can't seem to grok the coredump. Thanks for your input tho.

https://gist.github.com/YellowOnion/32051338b1a553c5ae51a0c667b14145

Consider making the PR draft for now to clearly indicate it’s not ready.

You may find upstream lib updates useful https://projects.blender.org/blender/blender/issues/136540.

Technically upstream used TBB 2021.13.0 in v4.4 https://projects.blender.org/blender/lib-source/commit/22606a34277e06b0ad348e7bb47eec0b7990bb4d

@silvanshade Blender seems to require 2021.13.0 now, I tried overriding all the deps, but maybe I missed some. Compiling everything takes 20mins, so It's a bit of a headache, and I can't seem to grok the coredump. Thanks for your input tho.

https://gist.github.com/YellowOnion/32051338b1a553c5ae51a0c667b14145

A lot of that output looks thread related but it's hard to tell if that means anything here. But looking through the CMake files, it does seem like it should be possible to change which version is used.

I would try modifying the related variables in versions.cmake:

https://github.com/blender/blender/blob/da82ed18f19507ff39a3c2f40f633a723af75af4/build_files/build_environment/cmake/versions.cmake#L367-L377

And the call to find_package_wrapper in platform_unix.cmake:

https://github.com/blender/blender/blob/da82ed18f19507ff39a3c2f40f633a723af75af4/build_files/cmake/platform/platform_unix.cmake#L547-L554

You could also try setting up ccache to help with build times while investigating.

EDIT: Also maybe try building with TBB completely disabled by setting WITH_TBB=OFF in the CMake variables? I guess that will disable some features but might get you far enough to see if that was the problem or not.

@silvanshade it looks like TBB introduced cmake files with v2021.13.0, and blender killed manual TBB support with v4.5, depending on those introduced files, so this explains why it now requires v13, but it also complicates the heck out of trying to use older versions of TBB, I might try debugging the issue more before making random guesses about what is causing the issue, thanks for your input anyway.

Found out the issue, I had to fetch with LFS, otherwise it would crash during runtime looking for files, No clue why it allows you to build and install without tossing errors, but I now have 4.5 working.

Can we make blender use tbb_2022?

@Prince213 basic testing shows Blender is stable running with 2022.

So tbb_2021 won't be needed and the file could be removed. Please also rebase against latest master as the tbb packages have migrated to by-name.

@Prince213 According to a Blender maintainer not directly familiar with TBB, they use the VFX Reference Platform 2025 which recommends 2021.x, I'm unsure what the difference between 2021.13 and 2022.x is, or why other packages are having issues with these versions, but it has me wary about shipping Blender against either version. Other distros seem to be skipping 2021.13 as well.

I have no experience with TBB, but my gut feeling is telling me that using 2021.12 is the best option, despite upstreams requirement for .13, we can revert the PR if we start seeing users complain about stability.

Also WRT to the build failure for nix, I don't see any issues on TBB upstream related to it, have you considered reporting it as a bug?

Looks like Arch Linux, Gentoo and Void Linux are all using 2022.x. Since nixos-unstable/nixpkgs-unstable are also providing latest packages I think we should use that as well.

As for the Nix issue I'll try building it later and see what can be done.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 415996
Commit: 129a9235ee69d22c452610b2d803991150e1d2c9

x86_64-darwin

I'm wondering if we should just mark OSX packages as broken till someone can fix it.

I also wonder, since 4.5 is an LTS release if we should have both, an LTS package, and the more standard latest release in the future.

Apologies for the delay, I’ll take a look later. I agree with marking Darwin as broken so this PR can move forward.

Update: After adapting our patch, I ran into a segmentation fault that needs further investigation.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 680723a1..1e009b76 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2601,7 +2601,7 @@ if(WITH_COMPILER_SHORT_FILE_MACRO)
   )
   if(C_MACRO_PREFIX_MAP AND CXX_MACRO_PREFIX_MAP)
     if(APPLE)
-      if(XCODE AND ${XCODE_VERSION} VERSION_LESS 12.0)
+      if(FALSE)
         # Developers may have say LLVM Clang-10.0.1 toolchain (which supports the flag)
         # with Xcode-11 (the Clang of which doesn't support the flag).
         message(
diff --git a/build_files/cmake/platform/platform_apple.cmake b/build_files/cmake/platform/platform_apple.cmake
index 763d32e9..c44728e1 100644
--- a/build_files/cmake/platform/platform_apple.cmake
+++ b/build_files/cmake/platform/platform_apple.cmake
@@ -55,7 +55,6 @@ if(NOT DEFINED LIBDIR)
   endif()
 endif()
 if(NOT EXISTS "${LIBDIR}/.git")
-  message(FATAL_ERROR "Mac OSX requires pre-compiled libs at: '${LIBDIR}'")
 endif()
 if(FIRST_RUN)
   message(STATUS "Using pre-compiled LIBDIR: ${LIBDIR}")
@@ -121,10 +120,6 @@ if(WITH_CODEC_SNDFILE)
   find_library(_sndfile_VORBIS_LIBRARY NAMES vorbis HINTS ${LIBDIR}/ffmpeg/lib)
   find_library(_sndfile_VORBISENC_LIBRARY NAMES vorbisenc HINTS ${LIBDIR}/ffmpeg/lib)
   list(APPEND LIBSNDFILE_LIBRARIES
-    ${_sndfile_FLAC_LIBRARY}
-    ${_sndfile_OGG_LIBRARY}
-    ${_sndfile_VORBIS_LIBRARY}
-    ${_sndfile_VORBISENC_LIBRARY}
   )
 
   print_found_status("SndFile libraries" "${LIBSNDFILE_LIBRARIES}")
@@ -168,9 +163,7 @@ if(WITH_CODEC_FFMPEG)
   set(FFMPEG_ROOT_DIR ${LIBDIR}/ffmpeg)
   set(FFMPEG_FIND_COMPONENTS
     avcodec avdevice avformat avutil
-    mp3lame ogg opus swresample swscale
-    theora theoradec theoraenc vorbis vorbisenc
-    vorbisfile vpx x264)
+    swresample swscale)
   if(EXISTS ${LIBDIR}/ffmpeg/lib/libaom.a)
     list(APPEND FFMPEG_FIND_COMPONENTS aom)
   endif()
@@ -285,7 +278,6 @@ endif()
 add_bundled_libraries(boost/lib)
 
 if(WITH_CODEC_FFMPEG)
-  string(APPEND PLATFORM_LINKFLAGS " -liconv") # ffmpeg needs it !
 endif()
 
 if(WITH_PUGIXML)
@@ -430,7 +422,7 @@ string(APPEND PLATFORM_LINKFLAGS
   " -Wl,-unexported_symbols_list,'${PLATFORM_SYMBOLS_MAP}'"
 )
 
-if(${XCODE_VERSION} VERSION_GREATER_EQUAL 15.0)
+if(FALSE)
   if("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "x86_64" AND WITH_LEGACY_MACOS_X64_LINKER)
     # Silence "no platform load command found in <static library>, assuming: macOS".
     #
diff --git a/source/blender/blendthumb/CMakeLists.txt b/source/blender/blendthumb/CMakeLists.txt
index a4419cda..fa80c51c 100644
--- a/source/blender/blendthumb/CMakeLists.txt
+++ b/source/blender/blendthumb/CMakeLists.txt
@@ -81,16 +81,6 @@ elseif(APPLE)
     # Prevent Xcode from overwriting the signature.
     XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY ""
   )
-  # CMake needs the target defined in the same file as add_custom_command.
-  # It needs to be code-signed (ad-hoc in this case)
-  # even on developer machine to generate thumbnails.
-  # Command taken from XCode build process.
-  add_custom_command(
-    TARGET blender-thumbnailer POST_BUILD
-    COMMAND codesign --deep --force --sign -
-      --entitlements "${CMAKE_SOURCE_DIR}/release/darwin/thumbnailer_entitlements.plist"
-      --timestamp=none $<TARGET_BUNDLE_DIR:blender-thumbnailer>
-  )
 elseif(UNIX)
   # -----------------------------------------------------------------------------
   # Build `blender-thumbnailer` executable

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 415996
Commit: fa478f30cd0569fc300b967c6a24a49ed5b8f7c6

aarch64-darwin

@ethancedwards8, please post build logs, not really sure why the build would suddenly fail on such a trivial change.

I guess openscad-unstable is not actually broken on aarch64-darwin. The failure seems to be caused by the sandbox.

error: derivation '/nix/store/virjklqrzpx1zj7wadadhpg0nxw773cm-openscad-unstable-2025-06-04.drv' specifies a sandbox profile, but this is only allowed when 'sandbox' is 'relaxed'

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 415996

Logs: https://github.com/yzx9/nixpkgs-review-gha/actions/runs/16416191683

aarch64-darwin (sandbox = relaxed)

Yes. The error was sandbox related. Sorry

Hello. I've noticed that the Vulkan backend introduced in 4.5 is not working in Blender's binaries (both through nix-ld and the blender-bin flake.) Can someone confirm this is the case? Confirmed this PR fixes it.

Steps to reproduce:

• Launch Blender
• Go to Edit > Preferences
• In the System tab, change the backend from OpenGL to Vulkan
• Restart Blender

Can it be marked as broken only for x86_64-darwin and allowed for aarch64-darwin?

Can it be marked as broken only for x86_64-darwin and allowed for aarch64-darwin?

Is it actually building there?

I can't build on aarch64-drawin after bumping the patch. Any investigation or helps would be appreciated

@yzx9 please post logs.

@YellowOnion Hi, I've opened a separate thread at #429309 to report this.