Wrong architecture python3 installed

[jms19]

I have a brand new Mac Mini, Arduino IDE installed today from an image called arduino-ide_2.3.6_macOS_arm64.dmg and this as want to do something on ESP8266.

But when I build it fails because the python3 installed is for x86.
fork/exec /Users/jms/Library/Arduino15/packages/esp8266/tools/python3/3.7.2-post1/python3: bad CPU type in executable

the file utility says this
./Library/Arduino15/packages/esp8266/tools/python3/3.7.2-post1/python3: Mach-O 64-bit executable x86_64

which is obviously wrong.

[mcspr]

which is obviously wrong.

not really. since there is no python3 speced for apple's arm arch in the package .json. it picks up the next best one - x86_64, which works through rosetta
see https://github.com/esp8266/Arduino/blob/master/package/package_esp8266com_index.template.json, search /python/

afaik, earlephilhower/arduino-pico uses similar packaging. just not sure what the versioning does here
https://github.com/earlephilhower/pico-quick-toolchain/releases/tag/4.0.1 search for /python3.18/
https://github.com/earlephilhower/arduino-pico/blob/8d58a9207f0a2665f53c5658250c349ff32939d6/package/package_pico_index.template.json#L684-L697

but, this arch spec has to happen for every tool in the .json, not just python

[earlephilhower]

Yes, you will need to use Rosetta emulation on ARM Macs for this because it's not just Python3 but all binaries which are your problem.

If it was only python, we could patch in the ARM-native binary built in pqt, but GCC, LD, etc. all need recompilation.

That's not really possible here because GCC-xtensa itself didn't build for ARM Macs until (IIRC) 14.1 and we're @ GCC 10 in this core. You can't use the GCC binaries in pqt because they're ARM targeted, not Xtensa, so can't build for the ESP8266.

[mcspr]

That's not really possible here because GCC-xtensa itself didn't build for ARM Macs until (IIRC) 14.1 and we're @ GCC 10 in this core.

Meaning, there is no need for external patch anymore for GCC itself?
(also iirc, I have tried that last year but got sidetracked when bumping other build tools)

[earlephilhower]

Yeah, for the ARM/R5 target at least GCC 14.2 builds without a single patch for ARM Mac hosts using osxcross under Linux. A 1-line patch to binutils to make GDB compiles pass was needed but no code touches.

We have ~90 functional patches (i.e. GCC xtensa backend logic is broken) in the 10.x we ship here which may or may not be in the upstream 14.x tree. The C++ exception magic to allow flash-stored unwind tables also would need to be ported (or completely disable exception support).

For 12.?? I believe there is a brew recipe with a bunch of patches which builds okay for Darwin and ARM targets, but breaks other hosts so it's not too useful for cross-platform work.

[mcspr]

Tnx, I'll focus on 14.2 then.
My understanding is a lot of xtensa-related patches were upstreamed, but would have to cross reference them by commit names
flashmem ones are obviously must be ported, and there are some kind of new headers related to xtensa config which do not seem to work atm :/