ELF load command address/offset not properly aligned
lainiwa opened this issue · comments
I am trying to debianize a python package, containing a few non pure-python libraries. I was excluding them in the debian/rules
:
override_dh_shlibdeps:
dh_shlibdeps -X/x86/ -X/numpy/.libs -X/cv2/.libs -X/PIL/.libs
up until dpkg-buildpackage
was able to create a .deb
file.
However, after installation, calling the package's entry point results in an error:
Traceback (most recent call last):
[ ... ]
import cv2
File "/opt/venvs/py3software/lib/python3.6/site-packages/cv2/__init__.py", line 3, in <module>
from .cv2 import *
ImportError: /opt/venvs/py3software/lib/python3.6/site-packages/cv2/cv2.cpython-36m-x86_64-linux-gnu.so: ELF load command address/offset not properly aligned.
I have read through this numpy issue mentioning similar problem, but I am still very lost.
Am I doing it the wrong way?
The other problem (mentioned in docs) is stripping. Also, layout seems to have changes (no .libs
).
For working code, see https://github.com/1and1/debianized-jupyterhub/blob/master/debian/rules#L47-L54
If that fixes your build, please close.
I tried this (copied override_dh_strip
from the file you linked and changed the layout to have no .libs
), but unfortunately this does not seem to change anything.
You have to list YOUR deps of course, in this case /cv2
.
Yes, of course I listed it:
override_dh_shlibdeps:
dh_shlibdeps -X/x86/ -X/numpy/ -X/cv2/ -X/PIL/
I mean, the package creation works just fine. The error fires when I try to execute a python script (an entrypoint) it provides.
I created a minimal python package, in case you might want to reproduce the error: https://github.com/lainiwa/py3software.
The problem is that you still strip certain libs, destroying them in the process.
I think @nailor wrongly referenced this thread, as the problem I am experiencing here is unlikely to be a consequence of what is discussed in that issue.
I am having virtualenv==15.1.0
and when .deb
installed, it does not create self-referencing links:
root@93961807e1d7:/app# ls -l /opt/venvs/py3software/lib/python3.6/importlib/abc.py
-rw-r--r-- 1 root root 10782 Oct 22 11:32 /opt/venvs/py3software/lib/python3.6/importlib/abc.py
root@93961807e1d7:/app# ls -l /usr/lib/python3.6/importlib/abc.py
-rw-r--r-- 1 root root 10782 Oct 22 11:32 /usr/lib/python3.6/importlib/abc.py
The problem is that your strip certain libs, destroying them in the process.
Am I right that it is a bug of some sort, and this behavior is not intended?
Otherwise, could you suggest some workaround/right way to install C-written libs? I saw debianized-jupyterhub
and it looks like the only thing you do with those "problematic" dependencies is excluding them in override_dh_shlibdeps
section of debian/rules
.
I thought about listing those libs as apt-get'able dependencies. The problem is I can probably do this with opencv
but not with dlib
.
Hi lainiwa,
I'm currently experiencing the same issue when packaging python packages. Did you manage to solve this in the end?
Cheers,
Sil
The problem is recognizing the difference between ´shlibdeps´ and ´strip´.
Hi lainiwa,
I'm currently experiencing the same issue when packaging python packages. Did you manage to solve this in the end?
Cheers,
Sil
Unfortunately, no. I failed this.
Hey, dh-virtualenv is an awesome tool. I believe you will find the answer to ELF question in the Loud ML repository: https://github.com/regel/loudml
See in file debian/rules how dh_strip is used.
If you get the ELF load
error again then add extra --exclude
in dh_strip as needed. Repeat this process until the ELF errors are gone and you will have a working package.
It worked for me with trial and error, but it worked. Having a CI test in place is probably a good idea to test it repeatedly and make sure it does not break.
If it helps, please give a star to the Loud ML repo!
Try this:
override_dh_strip:
dh_strip --exclude=/site-packages/
override_dh_shlibdeps:
dh_shlibdeps --exclude=/site-packages/
Not sure if its correct, but it seems to work OK for me. I sent in a PR to include in the docs.
Looks like there is a fix for the issue, closing the issue