Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python: fix cross-compilation of extension modules #53320

Closed
FRidh opened this issue Jan 3, 2019 · 12 comments
Closed

Python: fix cross-compilation of extension modules #53320

FRidh opened this issue Jan 3, 2019 · 12 comments
Labels
6.topic: cross-compilation Building packages on a different sort platform than than they will be run on 6.topic: python

Comments

@FRidh
Copy link
Member

FRidh commented Jan 3, 2019

Issue description

The changes in #53123 improve the cross-compilation situation of Python. It's now possible to produce functioning cross-compiled Python packages.

Neither the interpreter nor the packages will depend on the build machine. It does involve in both the interpreter and wrapPythonPrograms an ugly hack to rewrite shebangs from build Python to host Python. This is a general issue discussed in #33956. In this case I think we should somehow instruct distutils of our host Python.

Cross-compiling extension modules still fails. In the interpreter build we've nuked references to the compiler, and that seems to be an issue. When not cross-compiling, all goes fine though.

Steps to reproduce

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

@FRidh FRidh added 6.topic: python 6.topic: cross-compilation Building packages on a different sort platform than than they will be run on labels Jan 3, 2019
@FRidh
Copy link
Member Author

FRidh commented Jan 4, 2019

PYTHON_FOR_BUILD should supposedly always be set when cross-compiling. First, let's see whether we can set strictDeps = true; in buildPythonPackage and fix the outfall of that.

@Mic92
Copy link
Member

Mic92 commented Jan 5, 2019

cc @matthewbauer @Ericson2314

@FRidh
Copy link
Member Author

FRidh commented Jan 13, 2019

Useful changeset SynoCommunity/spksrc@6a071f8

@FRidh
Copy link
Member Author

FRidh commented Jan 13, 2019

We need to keep _sysconfigdata*.py when cross-compiling because it's needed for extension modules. Probably best put it in a separate output so we don't have Python depending on dev outputs.

Using export PYTHON_FOR_BUILD=${getBin pythonForBuild.interpreter} seemed to break cross-compilation of Python itself.

@matthewbauer matthewbauer added this to the 19.03 milestone Jan 14, 2019
@lheckemann lheckemann removed this from the 19.03 milestone Feb 25, 2019
@danbst
Copy link
Contributor

danbst commented Jan 10, 2020

Seems like we need a special Python for building extension modules (talking about cross-compiling numpy).

platform.machine() should return target platform

sysconfig.get_config_var('LDSHARED') should use target compiler.

@danbst
Copy link
Contributor

danbst commented Jan 10, 2020

Oh yeah, I've made numpy crosscompile, but with hacks. Given an overlay entry:

                python3 = super.python3.override {
                    packageOverrides = pythonself: pythonsuper: {
                        numpy = pythonsuper.numpy.overrideAttrs (old: {
                            _PYTHON_HOST_PLATFORM = pkgs.lib.removeSuffix "-" self.stdenv.cc.targetPrefix;
                            buildPython = self.buildPackages.python3;
                            patches = (old.patches or []) ++ [
                                (self.writeText "numpy-patch-cross-extensions.diff" ''
diff --git a/numpy/distutils/ccompiler.py b/numpy/distutils/ccompiler.py
index 14451fa..39dbf8f 100644
--- a/numpy/distutils/ccompiler.py
+++ b/numpy/distutils/ccompiler.py
@@ -140,7 +140,7 @@ def CCompiler_spawn(self, cmd, display=None):
             display = ' '.join(list(display))
     log.info(display)
     try:
-        subprocess.check_output(cmd)
+        subprocess.check_output([ (cmd[0] if cmd[0].startswith("${self.stdenv.cc.targetPrefix}") else "${self.stdenv.cc.targetPrefix}" + cmd[0]) ] + [ (arg.replace(os.environ['buildPython'], "${self.python3}")) for arg in cmd[1:]])
     except subprocess.CalledProcessError as exc:
         o = exc.output
         s = exc.returncode
diff --git a/numpy/random/setup.py b/numpy/random/setup.py
index a820d32..fa1d536 100644
--- a/numpy/random/setup.py
+++ b/numpy/random/setup.py
@@ -51,9 +51,9 @@ def configuration(parent_package=''', top_path=None):
         EXTRA_COMPILE_ARGS += ['-std=c99']
         INTEL_LIKE = any(arch in platform.machine()
                          for arch in ('x86', 'i686', 'i386', 'amd64'))
-        if INTEL_LIKE:
-            # Assumes GCC or GCC-like compiler
-            EXTRA_COMPILE_ARGS += ['-msse2']
+        #if INTEL_LIKE:
+        #    # Assumes GCC or GCC-like compiler
+        #    EXTRA_COMPILE_ARGS += ['-msse2']

     # Use legacy integer variable sizes
     LEGACY_DEFS = [('NP_RANDOM_LEGACY', '1')]
                                '')
                            ];
                        });
                    };
                    self = self.python3;
                };

it builds numpy without references to build python. @FRidh What is nice, your suggestion about nuked references wasn't an issue at all (e.g. it compiles even with refs nuked).

PS: I still haven't run this, so don't know if it works.

@FRidh
Copy link
Member Author

FRidh commented Jan 10, 2020

What is nice, your suggestion about nuked references wasn't an issue at all (e.g. it compiles even with refs nuked).

That's convenient, though we of course need to check that for more packages.

A fix: buildPython = self.python.pythonForBuild
Maybe we could add to the setup hook _PYTHON_HOST_PLATFORM if it is generic enough.

@stale

This comment has been minimized.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 8, 2020
@Ericson2314
Copy link
Member

It sounds like the basic issue is that configure-script-like-things are not aware of cross compilation at all.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 8, 2020
@FRidh
Copy link
Member Author

FRidh commented Jul 8, 2020

#91178 was a generic fix. I am not aware of any further issues, but then again, I don't use cross-compilation myself.

@FRidh
Copy link
Member Author

FRidh commented Nov 19, 2020

Splicing of Python packages in #104201.

@FRidh
Copy link
Member Author

FRidh commented Nov 19, 2020

I consider this fixed with #98915 and #104135. Let's see until we find more needs to be done 😄

Note pybind11 does not yet cross-compile, other than that all the packages I tried that have extension modules build.

@FRidh FRidh closed this as completed Nov 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: cross-compilation Building packages on a different sort platform than than they will be run on 6.topic: python
Projects
None yet
Development

No branches or pull requests

6 participants