Can't build borg on arm64 (armbian 22.04LTS) #8208
Comments
|
If you want to build borg 1.2.x (which is recommended as it is the stable release currently), you either need: or After that: If you don't do that, you are likely having master branch checked out, which is unsuitable for production usage. Note: if you have the virtual env activated, you are using the Cython version installed into there (3.0.10 as per your log), not you system cython 0.29. But usually that's good. |
|
About the log you posted: That seems to be a |
|
I restarted from scratch, and used "git checkout 1.2.8" in borg source directory to get the v1.2.8 release source files. Just to be sure what cython version is used I removed the cython package from the OS repos (so no more armbian/ubuntu native cython package). Then successfully activated python venv and required packages: And yet same error. It comes from the setup.py line 83 |
|
The root cause might be this line failing in setup.py: Can you invoke a python interpreter with your virtual env active and try that? If that fails, it is not a borg problem, but a |
|
cython import works in the venv: I can use cython to process a file too: Setting this environment variable gets me a step further: |
If you use the 1.2.8 checkout, better use the 1.2.8 tag to link to source files, like: https://github.com/borgbackup/borg/blob/1.2.8/setup.py The effect you have is weird. It seems that you can successfully import |
|
Using https://github.com/borgbackup/borg/blob/1.2.8/setup.py same issue. |
|
Can you try whether up/downgrading setuptools/pip/wheel helps (inside the venv)? |
|
Ok here is the upgrade path I followed in the venv : Upgraded all packages from requirements.d/development.txt to latest available version: same |
|
An hello world cythonized test actually works in borg's venv: https://gist.github.com/m33m33/4e45788ef563d08594ba27cd918dcaf7 |
|
Back to borg code base. At this point I can run this successfully To me it means that cythonization actually works, but not when running |
|
Additional test scenario:
|
|
During all these tests cases I noticed Actually this particular error is tied to the noexec mount option for /tmp. Here /tmp is a tiny tmpfs, because 1. it's an arm64 SBC and 2. you know you don't want malware binaries exec on /tmp anyway.
So let's remount /tmp without May I suggest adding a test for /tmp exec capability ? I will give it a try against v1.4 branch as to my understanding it's the next release candidate branche... |
|
Good catch! Is there a traceback for this ImportError? Also: can this "failed to map" error msg be seen if you remove the try/except in borg's setup.py? |
If you blindly import Cython without try/catch you get the same error. I think keeping the try/catch is a good idea but adding a warning in the except section is needed, because if you enter this section the rest will most likely fail at some point, right ? |
|
I am working on an improvement, PR will come soon, would be good if you can try it out. Can you try #8210? It is for 1.4-maint branch, but guess the patch might also apply to 1.2-maint. The goal is to get a clear error msg and not to hide the original error, making it easier to find the root cause of issues other than just "cython is not installed". |
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
|
Add "bug" label because borg's |
|
Here is the |
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
|
OK, I'll add a hint about +exec. |
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
…ckup#8208 Looks like borg's setup.py has hidden the real cause of a cythonize ImportError. There are basically 2 cases: - either there is no Cython installed, then the import fails because the module can not be found, or - there is some issue within Cython and the import fails due to that. It's important not to hide the real cause, especially if we run into case 2. case 1 is kind of expected and frequent, case 2 is rare.
That "failed to map segment from shared object" error msg is not very helpful. Add a hint that the filesystem needs to be +exec (== not noexec mounted, like it might be the case for /tmp on some systems).
…or-reporting-master setup.py: fix import error reporting for cythonize import, see #8208 (master)
…or-reporting-1.2 setup.py: fix import error reporting for cythonize import, see #8208
…or-reporting-1.4 setup.py: fix import error reporting for cythonize import, see #8208
|
OK, as far as borg is concerned, I'll close this - it now gives a helpful error message. The root cause of this is the noexec fs and that the pip build used that fs, so it is outside of borg. |
Have you checked borgbackup docs, FAQ, and open GitHub issues?
As best as I could
Is this a BUG / ISSUE report or a QUESTION?
ISSUE: can't build from sources (either pip or git, this issue is about building from sources using git)
System information. For client/server mode post info for both machines.
Your borg version (borg -V).
Looking forward to build the current version as per git clone
Operating system (distribution) and version.
Armbian, cat /etc/lsb-release :
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"
Hardware / network configuration, and filesystems used.
LePotato (arm64 SBC, mainline kernel support)
Describe the problem you're observing.
Following instructions from https://borgbackup.readthedocs.io/en/stable/installation.html#git-installation with GIT method.
Everything looks good from here:
Up to there:
As far as I can tell, cython is there as a regular package, plus in the pip virtual env...
I have a similar issue using the "pip" build method from the docs. It shouldn't be related specificaly to v1.2.8.
I'm pretty sure this is distribution specific, filing an issue just in case someone could help
The text was updated successfully, but these errors were encountered: