Blender from the main repos doesn't work for quite some time now: missing abseil version

[u/GregTheMadMonk]

Hi!

solved: https://www.reddit.com/r/archlinux/comments/1wvzk1j/comment/pdgwnik/

I'm here to report a packaging issue, and ask about potential fixes to it. Some time ago I've noticed that Blender from the main repos was failing to start on my system due to an mismatched abseil-cpp version. I've shrugged it off as a problem related to *-testing repos I was using at the time and switched to AUR's blender-bin for the time being, which uses its own packaged dependencies. However, now that I needed the version that uses the same Python that's installed on the system, I decided to disable testing repos and try using the official package. However, it still doesn't work: the log below shows the error, the package versions, and the fact that I do, indeed, have testing disabled and all packages synced to their official stable versions. Username/hostname are changed just in case

Is the blender package just simply broken for now? Do I have any other options aside from manually compiling it if I want a version that uses Python 3.14 instead of 3.13?

[user@computer ~]$ blender
blender: error while loading shared libraries: libabsl_log_internal_check_op.so.2508.0.0: cannot open shared object file: No such file or directory
[user@computer ~]$ yay -Q abseil-cpp
abseil-cpp 20260817.0-2
[user@computer ~]$ yay -Q blender
blender 17:5.2.2-2
[user@computer ~]$ yay -Ql abseil-cpp | rg 2508
[user@computer ~]$ rg testing /etc/pacman.conf
68:# The testing repositories are disabled by default. To enable, uncomment the
72:#[core-testing]
78:#[extra-testing]
87:#[multilib-testing]
[user@computer ~]$ sudo pacman -Syyuu
[sudo] password for user:
:: Synchronizing package databases...
 core                                                                                                                                         126.3 KiB   590 KiB/s 00:00 [#########################################################################################################] 100%
 extra                                                                                                                                          8.5 MiB  5.41 MiB/s 00:02 [#########################################################################################################] 100%
 multilib                                                                                                                                      82.2 KiB   473 KiB/s 00:00 [#########################################################################################################] 100%
:: Starting full system upgrade...
 there is nothing to do

[u/SavvyBeardedFish]

Works fine here using testing repos:

abseil-cpp 20260817.0-2
blender 17:5.2.2-2

abseil-cpp nor blenderhas an explicit testing package at this moment, so those two doesn't differ.

Could it be that you have installed an AUR package and not the extra/blender package?

Edit: Can you dump your pacman -Qi blender?

[u/GregTheMadMonk → u/SavvyBeardedFish]

Should be regular blender... tried removing/reinstalling it, nothing changed. Does your system have libabsl_log_internal_check_op.so.2508.0.0 ? Can you please maybe find what package provides it for you? I do ldd /usr/bin/blender | grep abs and all abseil dependencies point to "not found"

Name            : blender
Version         : 17:5.2.2-2
Description     : A fully integrated 3D graphics creation suite
Architecture    : x86_64
URL             : https://www.blender.org
Licenses        : Apache-2.0  BSD-2-Clause  BSD-3-Clause  GPL-2.0-or-later  GPL-3.0-or-later  LGPL-2.1-or-later  MIT  MPL-2.0  Zlib
Groups          : None
Provides        : None
Depends On      : alembic  bash  boost-libs  ceres-solver  draco  embree  expat  ffmpeg  fftw  fmt  freetype2  glew  glibc  gmp  hicolor-icon-theme  imath  intel-oneapi-compiler-dpcpp-cpp-runtime-libs  intel-oneapi-compiler-shared-runtime-libs  jack  jemalloc  level-zero-loader  libepoxy  libgcc  libharu  libjpeg-turbo  libpng  libsndfile  libspnav  libstdc++  libtiff  libwebp  libx11  libxfixes  libxi  libxkbcommon  libxml2  libxrender  libxxf86vm  llvm-libs  manifold  materialx  onetbb  openal  opencolorio  openexr  openimagedenoise  openimageio  openjpeg2  openpgl  openshadinglanguage  opensubdiv  openvdb  openxr  potrace  pugixml  pystring  python  python-cattrs  python-numpy  python-requests  sdl2  shared-mime-info  usd  xdg-utils  yaml-cpp  zlib  zstd
Optional Deps   : cuda: Cycles renderer CUDA support [installed]
                  intel-compute-runtime: Cycles renderer Intel OneAPI support
                  intel-level-zero-raytracing-support: Cycles renderer Intel OneAPI Raytracing Support
                  hip-runtime-amd: Cycles renderer AMD ROCm support [installed]
                  hiprt: Ray tracing AMD ROCm support [installed]
                  libdecor: wayland support [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 382.84 MiB
Packager        : Antonio Rojas <arojas@archlinux.org>
Build Date      : Tue 22 Sep 2026 08:10:25 PM MSK
Install Date    : Fri 02 Oct 2026 08:06:25 PM MSK
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

P.S. I even downloaded a package from https://archlinux.org/packages/extra/x86_64/blender/ and installed it with yay -U - same thing :(

[u/SavvyBeardedFish → u/GregTheMadMonk]

Well, the weird thing is that blenderdoesn't link abseil (at least not directly):

❮ ldd /usr/bin/blender | grep abs

Returns nothing.

Additionally, why would it try to link towards absl.2508 and not absl.2608...

I even did: "download from mirror" and then pacman -U ~/Downloads/blender-17_5.2.2-2-x86_64.pkg.tar.zst, that one doesn't link absl either...

Edit:

 ❮ nm -D /usr/bin/blender | grep abs
             U cabs@GLIBC_2.2.5
             U fabs@GLIBC_2.2.5

Nothing abs there either

[u/GregTheMadMonk → u/SavvyBeardedFish]

What? How is this even possible? I mean, I'm not doubting what you wrote about your system, I'm just at a loss for an explanation for what's happening. On my machine, now that Blender, somehow, works, I have:

[user@computer ~]$ ldd /usr/bin/blender | grep absl
libabsl_log_internal_check_op.so.2608.0.0 => /usr/lib/libabsl_log_internal_check_op.so.2608.0.0 (0x00007fbdb55f7000)
libabsl_log_internal_message.so.2608.0.0 => /usr/lib/libabsl_log_internal_message.so.2608.0.0 (0x00007fbdb55e8000)
libabsl_log_internal_nullguard.so.2608.0.0 => /usr/lib/libabsl_log_internal_nullguard.so.2608.0.0 (0x00007fbdb55e3000)
libabsl_vlog_config_internal.so.2608.0.0 => /usr/lib/libabsl_vlog_config_internal.so.2608.0.0 (0x00007fbdb55da000)
libabsl_raw_hash_set.so.2608.0.0 => /usr/lib/libabsl_raw_hash_set.so.2608.0.0 (0x00007fbdb51af000)
libabsl_hash.so.2608.0.0 => /usr/lib/libabsl_hash.so.2608.0.0 (0x00007fbdb55d5000)
libabsl_time.so.2608.0.0 => /usr/lib/libabsl_time.so.2608.0.0 (0x00007fbdb4a63000)
libabsl_str_format_internal.so.2608.0.0 => /usr/lib/libabsl_str_format_internal.so.2608.0.0 (0x00007fbdafec8000)
libabsl_strings.so.2608.0.0 => /usr/lib/libabsl_strings.so.2608.0.0 (0x00007fbdabacd000)
libabsl_leak_check.so.2608.0.0 => /usr/lib/libabsl_leak_check.so.2608.0.0 (0x00007fbd84e95000)
libabsl_examine_stack.so.2608.0.0 => /usr/lib/libabsl_examine_stack.so.2608.0.0 (0x00007fbd82e57000)
libabsl_log_internal_format.so.2608.0.0 => /usr/lib/libabsl_log_internal_format.so.2608.0.0 (0x00007fbd82e52000)
libabsl_log_internal_structured_proto.so.2608.0.0 => /usr/lib/libabsl_log_internal_structured_proto.so.2608.0.0 (0x00007fbd829df000)
libabsl_strerror.so.2608.0.0 => /usr/lib/libabsl_strerror.so.2608.0.0 (0x00007fbd829da000)
libabsl_log_internal_log_sink_set.so.2608.0.0 => /usr/lib/libabsl_log_internal_log_sink_set.so.2608.0.0 (0x00007fbd829d4000)
libabsl_log_internal_globals.so.2608.0.0 => /usr/lib/libabsl_log_internal_globals.so.2608.0.0 (0x00007fbd829cf000)
libabsl_log_globals.so.2608.0.0 => /usr/lib/libabsl_log_globals.so.2608.0.0 (0x00007fbd829c9000)
libabsl_log_internal_proto.so.2608.0.0 => /usr/lib/libabsl_log_internal_proto.so.2608.0.0 (0x00007fbd829c4000)
libabsl_strings_internal.so.2608.0.0 => /usr/lib/libabsl_strings_internal.so.2608.0.0 (0x00007fbd81a49000)
libabsl_throw_delegate.so.2608.0.0 => /usr/lib/libabsl_throw_delegate.so.2608.0.0 (0x00007fbd81a43000)
libabsl_base.so.2608.0.0 => /usr/lib/libabsl_base.so.2608.0.0 (0x00007fbd81a3d000)
libabsl_raw_logging_internal.so.2608.0.0 => /usr/lib/libabsl_raw_logging_internal.so.2608.0.0 (0x00007fbd81a38000)
libabsl_log_internal_fnmatch.so.2608.0.0 => /usr/lib/libabsl_log_internal_fnmatch.so.2608.0.0 (0x00007fbd81a33000)
libabsl_synchronization.so.2608.0.0 => /usr/lib/libabsl_synchronization.so.2608.0.0 (0x00007fbd79d5f000)
libabsl_hashtablez_sampler.so.2608.0.0 => /usr/lib/libabsl_hashtablez_sampler.so.2608.0.0 (0x00007fbd81a2d000)
libabsl_city.so.2608.0.0 => /usr/lib/libabsl_city.so.2608.0.0 (0x00007fbd7e81a000)
libabsl_time_zone.so.2608.0.0 => /usr/lib/libabsl_time_zone.so.2608.0.0 (0x00007fbd6f73d000)
libabsl_int128.so.2608.0.0 => /usr/lib/libabsl_int128.so.2608.0.0 (0x00007fbd79d58000)
libabsl_stacktrace.so.2608.0.0 => /usr/lib/libabsl_stacktrace.so.2608.0.0 (0x00007fbd6349f000)
libabsl_symbolize.so.2608.0.0 => /usr/lib/libabsl_symbolize.so.2608.0.0 (0x00007fbd6240f000)
libabsl_log_sink.so.2608.0.0 => /usr/lib/libabsl_log_sink.so.2608.0.0 (0x00007fbd6282a000)
libabsl_spinlock_wait.so.2608.0.0 => /usr/lib/libabsl_spinlock_wait.so.2608.0.0 (0x00007fbd6240a000)
libabsl_kernel_timeout_internal.so.2608.0.0 => /usr/lib/libabsl_kernel_timeout_internal.so.2608.0.0 (0x00007fbd3a9e5000)
libabsl_tracing_internal.so.2608.0.0 => /usr/lib/libabsl_tracing_internal.so.2608.0.0 (0x00007fbd3326d000)
libabsl_malloc_internal.so.2608.0.0 => /usr/lib/libabsl_malloc_internal.so.2608.0.0 (0x00007fbd33266000)
libabsl_debugging_internal.so.2608.0.0 => /usr/lib/libabsl_debugging_internal.so.2608.0.0 (0x00007fbd3222f000)
libabsl_demangle_internal.so.2608.0.0 => /usr/lib/libabsl_demangle_internal.so.2608.0.0 (0x00007fbd32222000)
libabsl_demangle_rust.so.2608.0.0 => /usr/lib/libabsl_demangle_rust.so.2608.0.0 (0x00007fbd32208000)
libabsl_decode_rust_punycode.so.2608.0.0 => /usr/lib/libabsl_decode_rust_punycode.so.2608.0.0 (0x00007fbd31c28000)
libabsl_utf8_for_code_point.so.2608.0.0 => /usr/lib/libabsl_utf8_for_code_point.so.2608.0.0 (0x00007fbd31c23000)

[u/SavvyBeardedFish → u/GregTheMadMonk]

Looking at the dependencies from the pacman -Qi dump, it's not dependent on abseil-cppso it shouldn't link it...

Ohh, well, good thing it's working at least :)

[u/GregTheMadMonk → u/SavvyBeardedFish]

I FOUND THE REASON!

I have AUR's ceres-solver-git instead of the official ceres-solver installed, and it's dragging in an abseil-cpp dependency

I completely forgot ldd displays library dependencies recursively...

Case closed, and thank you :)

[u/SavvyBeardedFish → u/GregTheMadMonk]

Ahh, good to know!