- Status New
- Percent Complete
- Task Type Bug Report
- Category Packages
- Assigned To No-one
- Operating System pentium4
- Severity Low
- Priority Medium
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Arch Linux 32
Opened by Andreas Baumann - 02.04.2022
Last edited by Andreas Baumann - 10.04.2022
Opened by Andreas Baumann - 02.04.2022
Last edited by Andreas Baumann - 10.04.2022
FS#246 - [blender] doesn't work (and doesn't build)
blender 2.93 has dependencies on wrong versions of
- llvm (via openshadinglanguage)
- boost (via openimageio)
Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)’
blender 3.0.1:
Haru not found, disabling WITH_HARU’ and ‘Cycles OSL requires WITH_LLVM, the library may not have been found. Configure LLVM or disable WITH_CYCLES_OSL
Let’s tackle one issue after the other.
lddtree shows:
OpenColorio:
This is hard-coded for being tested on the host, so this fails when
cross-compiling or building in a chroot.
openshadinglanguage fails with:
lddtree shows libtextstyle.so.0 comes from gettext which is stuck in a failing
test (which I will now simply ignore). The error is in gnulib, which is a library
fetched at build time in source form to various GNU project (as if shared libraries would
not exist). This makes patching them hard..
We have to force rebuilding of bison (why didn't it happen?)
So, gettext and bison are ready, so are the open* libraries.
Now we get into unported 32-bit problem territory:
So, adding float as a primitive helps (as float_t is something beatifuly
different on 32-bit).
So, now I get tons of errors here:
This is weird, as this means that the new blender being built is still linked
somehow againt an old TBB library.
aha, so we have to rebuilt embree..
Nice, this points to ispc, either we rebuild that against newer llvm or we use a
llvm10-libs shim.
ispc: I have a bad feeling about this:
We would need a clang10 (we don't have one), just to make the old ispc work again.
Let's see if we can drop embree from blender.. (though I have the feeling blender
could require with a ray tracer..):
bingo.
So, reactivating blender will be hard I'm afraid..
From mi side.
Blender 2.93:
Break llvm, clang and boost-libs dependences. I tried decompress this 3 packages in a new directory and tried run with LD_LIBRARY_PATH= with a segfault result (i maybe need test with a restart)
packages that need:
- llvm-libs-12.0.1-5.1-pentium4.pkg.tar.zst (or "llvm12" from the system)
- clang-12.0.1-1.2-pentium4.pkg.tar.zst
- boost-libs-1.76.0-2.1-pentium4.pkg.tar.zst
Blender 3.0.1:
Give a error from cmake: (tested with LD_LIBRARY_PATH=, llvm13, and llvm12, and python 3.9)
- "Haru not found, disabling WITH_HARU"
- "Cycles OSL requires WITH_LLVM, the library may not have been found. Configure LLVM or disable WITH_CYCLES_OSL"
- disable with -DWITH_CYCLES_OSL=Off , and now show a bunch of errors with Boost.
Blender 3.1.2:
Give a error from cmake:
- "Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)"
It seems that the one that works best is 3.0.1, at least close to it. The cmake line used is:
cmake .. -DCMAKE_BUILD_TYPE=Release -DWITH_CYCLES_DEVICE_OPTIX=OFF -DWITH_CYCLES_OSL=Off -DWITH_PYTHON_INSTALL=OFF -DWITH_INSTALL_PORTABLE=OFF -DPYTHON_VERSION=3.9 -DPYTHON_LIBPATH=/usr/lib -DPYTHON_LIBRARY=python3.9 -DPYTHON_INCLUDE_DIRS=/usr/include/python3.9 -DCMAKE_CXX_FLAGS="-I /usr/include/python3.9" -DWITH_CYCLES_CUDA_BINARIES=OFF -DWITH_CYCLES_DEVICE_CUDA=OFF -DWITH_RAYOPTIMIZATION=OFF -DBOOST_LIBPATH=/opt/DWN-T/SYS3/usr/lib -DBoost_INCLUDE_DIR=/opt/DWN-T/SYS3/usr/include/ -DWITH_HARU=OFF
(/opt/DWN-T/SYS3/ have old packages for llvm-12.0.1, boost-libs 1.76, and clang-12.0.1)
ispc probes for a AMD64 host and then does:
Fixing that gets me stuck in ispc (required by embree) with:
This could be a too old version of llvm..
@Killer Wasp: We could try to let blender alive as a library zombie by providing
shim libraries for boost, llvm, icu, etc. But then it goes the firefox way of the
dodo..
seems up to date (in staging).
Do we need genx at all? I try to disable that..
Good sign, the patch file is now longer than the PKGBUILD removing testing and GENX seems to produce a ispc binary (all we care for now)..
Rebuilding embree now..
Rebuilding blender now..
In principle it build, but now I have huge dependency issues around openimageio,
boost and friends to solve..
In stable we get now the same problem as with many other software:
I see no other uption but to
a) stick forever to python 3.9
b) push python 3.10 from testing to stable and clean up everything which is not
Now with the python issue out of the way I'm left with this:
which is:
could just be we have to push llvm too, but not before having a shim..
Disappeared and after a yaml-cpp push to stable, things work now (at least on pentium4)
Running on real hardware, pentium4 looks fine, i686 not:
This is some SSE optimization in embree.
I don't see how I can build embree on i686..