the RUNPATH for the extension library is wrong, depending on the build/ folder to exist beyond install

[soumith]

🐛 Bug

The installed file habitat_sim/_ext/habitat_sim_bindings.cpython-36m-x86_64-linux-gnu.so still uses the build/ folder to resolve it's dependencies. So, if after python setup.py install, if one removes the build/ folder, the installed habitat-sim stops working, because the _ext/habitat_sim_bindings on import, cant resolve the paths to libCorradePluginManager.so.2 and libCorradeUtility.so.2.

One can verify that this is happening by running:

readelf -d [python_install_folder]/lib/python3.6/site-packages/habitat_sim-0.1.4-py3.6-linux-x86_64.egg/habitat_sim/_ext/habitat_sim_bindings.cpython-36m-x86_64-linux-gnu.so | grep PATH

A simple fix that I used as a bandaid is to set the RPATH of this .so file to $ORIGIN, because the _ext folder correctly already contains those libCorrade* libraries. I can do this by:

patchelf --set-rpath '$ORIGIN' [python_install_folder]/lib/python3.6/site-packages/habitat_sim-0.1.4-py3.6-linux-x86_64.egg/habitat_sim/_ext/habitat_sim_bindings.cpython-36m-x86_64-linux-gnu.so

The correct fix is to set the RPATH for the generated extension library correctly within the build scripts

Command

# command that you run

python setup.py install
rm -rf build
cd docs # just get out of repository root directory
python -c "import habitat_sim"

Expected behavior

the above commands work

System Info

ENVIRONMENT INFO:
Platform: Linux-5.3.0-42-generic-x86_64-with-Ubuntu-18.04-bionic
Machine: x86_64
Processor: x86_64
Libc version: glibc 2.25
Mac version:
Python version: 3.6.9
Architecture: 64bit ELF
Win version:
System OS: Linux
Release: 5.3.0-42-generic
Version: #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020
Operational System: linux
GCC version: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMAKE version: cmake version 3.10.2
NVIDIA-SMI: Fri Apr 24 03:09:10 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21       Driver Version: 435.21       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX TIT...  Off  | 00000000:17:00.0 Off |                  N/A |
| 22%   35C    P8    15W / 250W |      1MiB / 12212MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX TIT...  Off  | 00000000:65:00.0  On |                  N/A |
| 22%   37C    P8    16W / 250W |    435MiB / 12211MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
Pip packages versions:
numba==0.49.0
numpy-quaternion==2020.4.21.14.53.58
tqdm==4.45.0
Conda packages versions:

[erikwijmans]

Ah yeah -- I remember running into this with the conda build setup. @mosra you said there may be a way to to this with cmake: https://github.com/facebookresearch/habitat-sim/pull/445/files#r371710997 ?

[erikwijmans]

Looking at the build script for conda, it looks like we have the same issue with the python components of magnum/corrade: https://github.com/facebookresearch/habitat-sim/blob/master/conda-build/habitat-sim/build.sh#L63-L64

[soumith]

yes, you can set RPATH with CMake and also in setup.py where relevant. You can look at pointers from the PyTorch repo:

• CMake: https://github.com/pytorch/pytorch/blob/3bdc4a37ed802f69a032179c1540aee6529eb2c1/torch/lib/libshm/CMakeLists.txt#L35 and https://github.com/pytorch/pytorch/blob/ff21b156246e16e939b4f87fe20964e2dbb40dc8/cmake/Dependencies.cmake#L3-L8
• setup.py: https://github.com/pytorch/pytorch/blob/ff21b156246e16e939b4f87fe20964e2dbb40dc8/setup.py#L639 and https://github.com/pytorch/pytorch/blob/ff21b156246e16e939b4f87fe20964e2dbb40dc8/setup.py#L660

[soumith]

the conda-build patchelf hacks we have in the PyTorch builder repos, I wrote them before we fixed the build system correctly. They can, I believe removed now, but we never got around to it.