0

I am running python on a m1 Mac with Rosetta, on a x86_64 architecture.

During the execution I need to use subprocess.run to launch some external program. However that program need to run under arm64 architecture.

Is there a possible solution for doing that? Simply running from an arm64 terminal does not do the trick, and it gets overridden by the Python architecture.

I am using python==3.8.2.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Dinari
  • 2,487
  • 13
  • 28
  • `subprocess.run` is not aware of things like architecture. How do you normally run `arm64` programs on your machine? You would do it the same way using `subprocess.run`. – gspr Nov 29 '22 at 13:44
  • Simply using arm64 terminal works. e.g. if I take the subprocess run command (outside python) it works. – Dinari Nov 29 '22 at 13:45
  • What does "using [an] arm64 terminal" entail? Surely it sets up some environment distinct from the x86_64 one? – gspr Nov 29 '22 at 16:16
  • Working with a M1 Mac you can choose to either work on arm64 architecture or x86_64. When opening a new terminal you can choose which architecture you want. In my case I need to use Python on x86, and some other program on arm64. – Dinari Nov 29 '22 at 17:01
  • The question is: what does opening a terminal for either architecture choice actually entail? Does it, for example, mean that some new environment variables are set up? – gspr Nov 29 '22 at 19:20
  • 1
    Isn't `subprocess.run` ultimately just making an `execve` system call? Does that not work transparently for either an ARM64 or x86-64 binary, replacing the forked process with one of the other architecture? What error message are you getting, and what does `dtrace` say when you use it to trace system calls? – Peter Cordes Nov 29 '22 at 19:30
  • I was getting an error message in the spawned process that it cannot run in x86_64 architecture. Yes it is making an exec call, and it's using the caller architecture. – Dinari Dec 01 '22 at 09:50

1 Answers1

1

The root of the problem was actually not in the subprocess.run, the process I was trying to spawn was compiled such that the binary is multi-arch support, supporting both arm64 and x86_64 (the support for the latter was mainly launching the program and crashing after not supported error).

As the call for subprocess.run came from a x86_64 architecture, the binary defaulted to that architecture.

The solution was to just compile the binary only for arm64, with no multi-arch support. After that the process was spawned with the correct architecture, even tho the call was made from a different architecture.

Dinari
  • 2,487
  • 13
  • 28