search

cheng-chi / blender_notebook

A simple command line tool to wrap blender 2.8+ as a jupyter kernel.
MIT License
70 stars 18 forks source link

Problem when integrating with OpenEXR #3

Closed WangYixuan12 closed 3 years ago

WangYixuan12 commented 4 years ago

I would like to use OpenEXR in my project. However, when I import OpenEXR in blender kernel. It returns

ImportError                               Traceback (most recent call last)
<ipython-input-1-a5220a657b46> in <module>
----> 1 import OpenEXR

ImportError: libIex.so.25: cannot open shared object file: No such file or directory

However, when I import OpenEXR in Python kernel, it works well. My command to install OpenEXR is pip install openexr. Btw, another thing confusing me is that if I install blender notebook in conda environment 1, it seems that I can still access it in another conda environment, which is weird for me.

cheng-chi commented 4 years ago

Blender notebook is installed as a jupyter kernel, which is a per-user cross virtual-environment config. So it should be able to access it in another conda environment.

cheng-chi commented 4 years ago

The rule of thumb for debugging dynamic library linking issue is to check your environmental variables. PATH, LD_LIBRARY_PATH etc. Just print the environment variables in both python blender and check the difference. Also check your bashrc scripts.

WangYixuan12 commented 4 years ago

I am sorry that I am new to debugging the dynamic library linking issue. After outputting those variables, what should I do to continue debugging? Would you like to share more things about how to debug this problem? Btw, I found one way to get around this problem by not importing OpenEXR lol. But I would like to continue debugging on this.

cheng-chi commented 4 years ago

It looks like the openexr python module is not able to find "libIex.so.25". What I usually do is to do a full file system search using "locate" to find where is this find, and check if the directory containing it is weird, or the symbolic link is created incorrectly, or if the containing directory is in LD_LIBRARY_PATH. The path to the dynamic library can also be encoded in the binary/library that invokes it using RPATH. You can use "ldd" to check if all required dynamic libraries of a library/binary can be found by the OS, and use "readelf" to directly check the RPATH. Unfortunately, the dynamic library linking problem is a really nasty problem, and there's really isn't a canonical way to solve every one of them. However, the process I just mentioned should at least point you in the right direction. I'm glad that you can get around the problem.