2
$\begingroup$

I have successfully built Blender-2.80-Beta as bpy (as in make bpy) for linux in Ubuntu 18. Also when i do make install on the same system i can sucessfully use import bpy.

However i don't know what the best approach would be to install the bpy-build to another different linux system. For me it is not really an option to also do the "make bpy" on that other system, since that system has very limited resources (400MB of free hard disk space)

Some approaches i can think of:

  1. Is there maybe a (automatic/manual) way to do make install with changed directories for python3.7, ... etc. ?
  2. Or is there a reasonable manual way to install? (The library is only bpy.so and the 2.80 Folder right?)
  3. Or can i maybe build to a virtual environment, install there and then copy the whole environment to the other linux system for it to work there?

I have tried copying bpy.so and the 2.80 folder to the other-systems site-packages but while it reads printTest.py it cannot use import bpy as seen in the picture:

enter image description here

Thank you for any help!! :)

Improve this question
$\endgroup$
  • $\begingroup$ I would think as long as it's for the same architecture it should work (in theory). You'd need separate builds for x86 and x86-64/amd64 as far as I'm aware. $\endgroup$ – Robert Gützkow♦ Jul 14 '19 at 15:58
  • $\begingroup$ Have you tried copying the lib and folder to other machine's python (of the same version) site packages? $\endgroup$ – batFINGER Jul 14 '19 at 16:16
  • $\begingroup$ @batFINGER i added a picture to the question of what happened when i tried doing that. $\endgroup$ – Robert Roth Jul 14 '19 at 16:29
  • 2
    $\begingroup$ Blender uses the libraries that are installed as dependencies when setting up a build. Make sure these libraries are also on other system. eg packages.ubuntu.com/bionic/libjemalloc-dev Could use the option to build with static libraries. btw Not sure where it's at, re questions about building blender as being off-topic. $\endgroup$ – batFINGER Jul 14 '19 at 17:50
4
$\begingroup$

This is not really an answer, not my knowledge either. Wanted to add this as a comment, but I don't have enough reputation to do so.

I asked Campbell Barton several years ago about how to build blender so I could share my builds with people that used a different distro than I did, and this is what he replied:

There are a few issues here, First is with general libraries - if the users doesnt have those exact libraries, blender wont start. To find the libraries blender depends on do...

objdump -x blender.bin | grep NEEDED

You can do this too, it will show all indirect dependencies too.

ldd blender.bin

There are 2 ways to go about this,

*) statically link all libraries

*) include the libraries and use LD_PRELOAD_PATH to ensure they get found, this requires a wrapper script. to set the environment variable.

Statically linking libs is best if you can, but for that you will need ".a" files, so not libpython3.2.so --> libpython3.2.a

however not all libraries come with static versions by default... it can be a hassle to get them all.

There are docs on static linking libs, you can check online for more info.

Also be sure to static link libgcc_s.so.1 and libstdc++, gcc has some options for this.

once you have this sorted out the main remaining problem is linking against libc, since you cant run blender on and older linux distro if you linked with a newer glibc (normally called libc.so.6).

To workaround this you need to link against an older glibc, This can be done by setting up a chroot environment that uses an older libc. or simply by using a VM with an older linux distro installed, both are a hassle :S.

Try google: linux link against older glibc It comes up with some useful links.

Note that for our official linux builds we have a chroot with some older libs installed so blender loads on older linux installs too.

Hope that helps!

Improve this answer
$\endgroup$
  • 1
    $\begingroup$ You want to use ldd bpy.so not blender.bin. The target machine needs all dependencies to be installed. Turn off features you don't need to reduce the overhead. eg. turn off OSL, openvdb, collada, alembic. $\endgroup$ – sambler Jul 17 '19 at 9:24
  • $\begingroup$ Thank you rijnswand and @sambler! :) I have spent quite some time trying to get it to work, but i'm somehow stuck at properly statically linking a library. Could you maybe provide a small example of how or where i would statically link a library? Do i need to add some code to some of the Cmake files? And if so in what file do i need to do the changes for that (i.e There is no CMakeLists.txt in my build_linux_bpy folder, so should i maybe change the link.txt file)? Or does it only have to do with the CMake variables (where the paths are set etc.)? $\endgroup$ – Robert Roth Jul 25 '19 at 7:25
  • 1
    $\begingroup$ @RobertRoth At the top of the blender source tree you will find the main CMakeLists.txt. From the build dir you can run ccmake <path/to/source> or cmake-gui to adjust the available options, press T to see all available. You will find WITH_STATIC_LIBS as well as WITH_OPENMP_STATIC and if you are enabling OSL LLVM_STATIC. $\endgroup$ – sambler Jul 27 '19 at 3:02
  • 1
    $\begingroup$ @RobertRoth I wouldn't say to expect 100% static build, just reduce them as much as possible. The linux builds available for download have a lib folder with libgl in them, try copying any remaining libs into this folder before copying across to the other machine. $\endgroup$ – sambler Jul 28 '19 at 7:52
  • 1
    $\begingroup$ @RobertRoth the linux downloads available from blender.org unzip to have a lib folder with the blender binary, that would be lib inside the build dir. Try copying libs into there before copying it over to the other machine. Failing that you could make a list of what needs to be installed, I'd properly install a few packages before copying libs into standard system lib folders. $\endgroup$ – sambler Jul 29 '19 at 0:29
1
+100
$\begingroup$

To understand this, you have to get a bit into the Unix (and thus Linux) Library loading system.

The object file is dynamically linked, which you can see by running file bpy.so. Dynamically linked objects require other libraries at runtime. You can see the required libraries by running ldd bpy.so.

There area also statically linked libraries, called "archives", they typically end in .a (Note that the ending is never causing the type, rather than the bytecode itself). On my system, there's the file /usr/lib/libtkstub8.6.a and running file on it yields: libtkstub8.6.a: current ar archive. No word about dynamic. And you can double-check with ldd libtkstub8.6.a: not a dynamic executable. That means this file does not require other libraries at runtime. They are considered portable.

To get the compiled binary working on another system, you have following options:

  • You stay with the dynamic library and try to replicate the system environment by copying all libraries ldd specifies at the exact same location on the target system. (You also have to copy the dependencies of those libraries, etc...)

  • You create a static library, which you can place wherever you like. It will be larger (since it has all the necessary functions in the file itself), but completely portable. Check out this guide (scroll to "Static Linking")

Improve this answer
$\endgroup$
  • $\begingroup$ I'm very grateful for your answer :) and i have spent quite some time trying to get it to work, but i'm somehow stuck at properly statically linking a library. Could you maybe provide a small example of how or where i would statically link a library? Do i need to add some code to some of the Cmake files? And if so in what file do i need to do the changes for that (i.e There is no CMakeLists.txt in my build_linux_bpy folder, so should i maybe change the link.txt file)? Or does it only have to do with the CMake variables (where the paths are set etc.)? $\endgroup$ – Robert Roth Jul 24 '19 at 19:42
  • $\begingroup$ Sorry for late response, was offline a few weeks... I do have no experience with cmake at all, but I'll try to get a build working. Gonna respond again, if I got one. $\endgroup$ – Filius Patris Aug 4 '19 at 10:29
  • $\begingroup$ @RobertRoth Where are you stuck? I get pretty good-looking results... $\endgroup$ – Filius Patris Aug 4 '19 at 12:58
  • $\begingroup$ What were you trying? How would you for example statically link the libjemalloc library? For example if i try to just edit the path in ccmake to the static library version i will get a ... need to recompile with -fPIC error... (I tried modifying the install-deps.sh to add -fPIC to cflags and cppflags but it wouldn't solve that problem). Maybe my approach is wrong? $\endgroup$ – Robert Roth Aug 4 '19 at 16:36
  • $\begingroup$ I solved my problem by setting LD_LIBRARY_PATH on the other filesystem and using the libjemalloc library as shared library. It works now! Thank you for all your help! $\endgroup$ – Robert Roth Aug 10 '19 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.