2

I am using cython to cross-compile external python module. I am using python3.6 on the host and python3.5 on the target. Also I am compiling on x86_64 for target aarch64.

My setup.py looks like:

from distutils.core import setup
from distutils.extension import Extension
from Cython.Build import cythonize
from Cython.Distutils import build_ext
import builder_config
import os

os.environ["PATH"] = builder_config.PATH
os.environ["CC"] = builder_config.COMPILER
os.environ["LDSHARED"] = builder_config.COMPILER + " -lpython3.5m -shared"
os.environ["CFLAGS"] = builder_config.CFLAGS
os.environ["LDFLAGS"] = builder_config.LDFLAGS
os.environ["ARCH"] = "aarch64"

setup(
    ext_modules = cythonize((Extension("my_ext", ["file1.pyx", "file2.pyx", "file3.pyx", "file4.pyx", "file5.pyx"]))),
)

When I run python3.6 setup.py build_ext -i I get a file named: my_ext.cpython-36m-x86_64-linux-gnu.so

My problem is that on the target the library will not be loaded unless the name is changed to:

my_ext.cpython-35m-aarch64-linux-gnu.so

How can I change the generated filename?

ErectCrested
  • 56
  • 1
  • 10
  • Maybe this helps : https://stackoverflow.com/questions/38523941/change-cythons-naming-rules-for-so-files – dejanualex Jan 22 '20 at 21:56
  • 2
    What you're trying to do is not safe; actually compiling with Python 3.6 is highly likely to take dependencies on features not present in Python 3.5. Simply changing the name will allow you to *try* to import it, but it's likely to be broken in one way or another. Unless you're using the [stable ABI](https://docs.python.org/3/c-api/stable.html) (and Cython most certainly does not), you can't compile for *any* minor version of Python and expect the same binary to work on a different minor version. – ShadowRanger Jan 22 '20 at 22:09

2 Answers2

0

As stated in the comments, what you are trying to achieve is unsafe.

You can work around the architecture tag with the environment variable _PYTHON_HOST_PLATFORM (e.g. you can change it in your sitecustomize.py). But, if the modules are actually incompatible (and they most likely are), you will only get core dumps later on.

I don't think you can work around the major Python version.

In order to come back to safer grounds, I would try to rely on portable solutions. For example, it doesn't look official, but we can find some articles on the web about Conda and aarch64 (e.g. you can look for 'Archiconda'). One more time, you wouldn't be able to simply copy the conda environments from one machine to another, but, you can freeze these environments (via a 'conda export') and build similar ones on the target machine.

FLemaitre
  • 503
  • 2
  • 9
0

An option is to upgrade the target interpreter to v3.6 if that's possible for you.

Another option is to install v3.5 on the machine you're using to build with that interpreter. It's pretty uncomplicated to get several different versions of the python interpreter installed on the same machine. I don't know your specifics so I can't provide any links but I'm sure a quick search will get you what you need.

JerodG
  • 1,248
  • 1
  • 16
  • 34