When I start blender I get this error.
/usr/bin/blender: error while loading shared libraries: libboost_python312.so.1.83.0: cannot open shared object file: No such file or directory
Its linking to the old library
lddtree $(which blender) | grep boost
libboost_thread.so.1.86.0 => /usr/lib/libboost_thread.so.1.86.0
libboost_filesystem.so.1.86.0 => /usr/lib/libboost_filesystem.so.1.86.0
libboost_atomic.so.1.86.0 => /usr/lib/libboost_atomic.so.1.86.0
libboost_python312.so.1.83.0 => None
libboost_python312.so.1.86.0 => /usr/lib/libboost_python312.so.1.86.0
libboost_iostreams.so.1.86.0 => /usr/lib/libboost_iostreams.so.1.86.0
libboost_filesystem.so.1.83.0 => None
libboost_locale.so.1.83.0 => None
libboost_thread.so.1.83.0 => None
libboost_iostreams.so.1.83.0 => None
I have tired reinstalling both blender and boost-libs
Same, reinstalling/downgrading didn't work for me either. Looks like a packaging problem. For some reason updating Blender always leads to the same errors with library links . I'm using the unofficial AppImage by erroreutopia until it's fixed.
I've been having issues getting it to build. In the meantime, if you have Arch repos enabled, installing extra/blender will work.
I have the exact same issue, and I updated today, its definitely a repo problem
Here's the build log (https://paste.artixlinux.org/view/94351d8c) if anyone wants to take a crack at it. Still not building.
Updated everything today, still not running
For what it's worth it fails in the same place, same errors, building in a clean arch chroot.
At some point if I remember I'll try it on bare metal as the only other thing I can think of is kernel differences ?
Otherwise how Arch are producing the package I'm not sure ?
Thank you for the investigation! I don't have enough ram on my personal machine to attempt builds locally so I couldn't try in Arch. You never know how the Arch maintainers build stuff because they don't always build in a clean chroot anyway.
Looking at it a bit more this seems to be the main problem in your build log
Line 2094
[2024-09-15T23:08:12.916Z] icpx: warning: ocloc tool could not be found and is required for AOT compilation. See: https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compilation/ahead-of-time-compilation.html for more information. [-Waot-tool-not-found]
But an ocloc binary is not part of any of the dependencies in the Arch PKGBUILD?
On Arch
pkgfile ocloc
extra/intel-oneapi-basekit
But intel-compute-runtime (is a dependency) does contain a /usr/bin/ocloc-24.35.1
Linking that to /usr/bin/ocloc made that error go away but there are now other errors (strangely they appear to occur earlier than the ocloc one ?) all following a similar pattern
[933/5827] Generating kernel_optix_osl_services.ptx
FAILED: intern/cycles/kernel/kernel_optix_osl_services.ptx /home/lee/blender/src/build/intern/cycles/kernel/kernel_optix_osl_services.ptx
cd /home/lee/blender/src/blender/intern/cycles/kernel && /opt/cuda/bin/nvcc --ptx -arch=sm_50 --relocatable-device-code=true -I /home/lee/blender/src -I /home/lee/blender/src/blender/intern/cycles/kernel/.. -I /home/lee/blender/src/blender/intern/cycles/kernel/device/cuda --use_fast_math -Wno-deprecated-gpu-targets -o /home/lee/blender/src/build/intern/cycles/kernel/kernel_optix_osl_services.ptx -D OSL_LIBRARY_VERSION_CODE=11310 osl/services_optix.cu
/usr/include/c++/14.2.1/x86_64-pc-linux-gnu/bits/c++config.h(827): error: user-defined literal operator not found
typedef __decltype(0.0bf16) __bfloat16_t;
^
/usr/include/c++/14.2.1/type_traits(529): error: type name is not allowed
: public __bool_constant<__is_array(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(529): error: identifier "__is_array" is undefined
: public __bool_constant<__is_array(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(581): error: type name is not allowed
: public __bool_constant<__is_member_object_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(581): error: identifier "__is_member_object_pointer" is undefined
: public __bool_constant<__is_member_object_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(603): error: type name is not allowed
: public __bool_constant<__is_member_function_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(603): error: identifier "__is_member_function_pointer" is undefined
: public __bool_constant<__is_member_function_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(695): error: type name is not allowed
: public __bool_constant<__is_reference(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(695): error: identifier "__is_reference" is undefined
: public __bool_constant<__is_reference(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(731): error: type name is not allowed
: public __bool_constant<__is_object(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(731): error: identifier "__is_object" is undefined
: public __bool_constant<__is_object(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(760): error: type name is not allowed
: public __bool_constant<__is_member_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(760): error: identifier "__is_member_pointer" is undefined
: public __bool_constant<__is_member_pointer(_Tp)>
^
/usr/include/c++/14.2.1/type_traits(3247): error: type name is not allowed
inline constexpr bool is_array_v = __is_array(_Tp);
^
/usr/include/c++/14.2.1/type_traits(3271): error: type name is not allowed
__is_member_object_pointer(_Tp);
^
/usr/include/c++/14.2.1/type_traits(3281): error: type name is not allowed
__is_member_function_pointer(_Tp);
^
/usr/include/c++/14.2.1/type_traits(3298): error: type name is not allowed
inline constexpr bool is_reference_v = __is_reference(_Tp);
^
/usr/include/c++/14.2.1/type_traits(3315): error: type name is not allowed
inline constexpr bool is_object_v = __is_object(_Tp);
^
/usr/include/c++/14.2.1/type_traits(3328): error: type name is not allowed
inline constexpr bool is_member_pointer_v = __is_member_pointer(_Tp);
^
/usr/include/c++/14.2.1/bits/utility.h(237): error: __type_pack_element is not a template
{ using type = __type_pack_element<_Np, _Types...>; };
It looks like maybe the installed cuda and gcc aren't getting along?
I very briefly tried using gcc13 but got nowhere with that.
I accept defeat for now.
Changed nothing and now it builds. Fingers crossed the rebuild for ffmpeg 7.1 also succeeds.
I'd argue that Blender should be just downloaded from official website as a portable package due to having separate python binaries and environment, Arch/Artix have their own system env that blender addons could inadvertently fuck over simply because most of the new addons can have internet access and could use something pip-like to install whatever it wants to the system environment.
It is solved by default by doing `sudo pacman -Syu`, confirmed it today. It installed `blender-17:4.2.3-1` and it works out of the box. I did nothing recommended above. Thank you to whoever fixed it <3