I am trying to build Blender as a Python module. I am also trying to do this on Raspbian.
I know both the environment and the “as a Python module” are unsupported, but I just wanted to document some of the difficulties that I had along the way, and if anyone has any ideas for how to correct the errors, that would be much appreciated!
Limitations
First off, the whole setup process is manual cmake. I basically went through some of the dependencies and installed what I could, but some functionality will not be compilable due to unavailability of some of the dependencies.
NOTE: I’m unable to build with Cycles since OpenEXR>=2 is not provided in Raspbian
What makes matters more difficult is that compiling with make install -j 4 is unfeasible due to the low memory of the Pi (I am using Pi3). So the trial and error method is somewhat limited.
Build Script
mkdir .blenderpy
mkdir .blenderpy/master
mkdir .blenderpy/master/build_bpy_raspbian
cd .blenderpy/master
git clone http://git.blender.org/blender.git
cd blender
git submodule update --init --recursive
git submodule foreach git checkout master
git submodule foreach git pull --rebase origin master
make update
build_files/build_environment/install_deps.sh
cd ../build_bpy_raspbian
cmake ../blender -DWITH_CYCLES=OFF -DWITH_PYTHON_INSTALL=OFF -DWITH_PYTHON_MODULE=ON
make install
Technically, 32 bit is no longer officially supported, so you might have more luck building 2.80 release instead of master. While I don’t expect any deliberate changes, the lack of 32bit testing of changes could allow a change to break 32bit builds. It may also be an arm (PI?) specific adjustment is needed.
The makesdna/makesrna part of blender is very picky when it comes to aligning struct members, this is to allow both 32 and 64 bit builds to read the same data, which keeps blend files readable on every system.
Compilers align struct members based on data size, which varies per target cpu, what that means is a short followed by a long could get two bytes of padding between them on a 64bit system but not a 32bit. To build blender we need to manually add padding to always match all possible compiler alignments. Also see blenders expected alignment sizes listed at the end of this post.
Your errors show failure in bGPDstroke as well as Scene. The fix is to find the struct members that are out of alignment and add padding.
all fields as far as makesdna is concerned are aligned properly for the layouts it tests for (if not it would have warned saying hey this field needs X bytes padding), what is happening in this instance is makesdna is happy with how things look, any by its math the bGPDstroke structure should be 372 bytes, the compiler however did something unexpected and inserted some extra padding ‘somewhere’ leading to a larger structure.
The trick now is gonna be locating where it did that, making an identical change in the blender headers and hope it is not violating makesdna’s alignment rules.
Yes, the “compiler did something unexpected” is what we need to adjust for, so that the compiler always aligns members to the location we expect. The extra padding added is why the expected size does not match the actual size of the struct.
Build and run this on your PI and compare output to an x86 build.
any progress on this? - anything i can do to help?
i have the same problem building for parabola/arch in a generic armv7h QEMU VM - the result is the same with or without the “cycles” option, and is not related to python modules, nor peculiar to the OP’s armv8 - FWIW, the same codebase and configuration builds fine on x86_64, i686 and aarch64 - in contrast to what the thread title indicates, sambler’s presumption was most likely correct, that this is not peculiar to any particular device, OS, or features, but is probably general to 32-bit ARM
the ‘dna_verify’ code compiled using LazyDodo’s patch - that appears to have worked; but i cant verify total success yet, because i hit a different error - the error seems t be related to the toolchain though - i will need to look into it more
i got past the toolchain problem and blender at git tag ‘v2.81a’ , compiled successfully in the parabola/arch armv7h QEMU VM, with LazyDodo’s patch applied
seeing this is a forum and not a bug tracker, i suppose i should ask if there is any chance of getting the bug verified by the dev team, and this patch upstreamed - is that why you were asking for a VM image @ideasman42 ? - the images need to be bootstrapped from a running arch-like system, and we dont normally publish any; but i could publish one if that would be useful
An easy way to test this on ARM32 + QEMU would be nice, pre-built image or not. From the wiki I didn’t see straightforward instructions to set this up.
Someone who has done this before could list the steps in a single document.
there is just not any straight-forward general way to do it, without a pre-made image, or bootstrapping a fresh one with the ‘parabola-vmbootstrap’ program - the standard procedure, described on the wiki, is to explode a pre-made tarball onto a real device, or to bootstrap a fresh install from another system
it would be no trouble for me to publish a “ready-to-boot out-of-the-box” QEMU image - there is none now, only because it is just not a popular use-case
It has it, since we don’t build for arm ourselves it wouldn’t hurt if you could give it a try and validate it works now, there is still time for additional fixes for 2.82.