5beta no M1 support

[kr15uk]

Application Version

5beta

Platform

macOS Monterey

Printer

Ultimaker 2 Go

Reproduction steps

Downloaded latest 5beta, run an app and opened ActivityMonitor and sorted by Kind to see "M1 support"

Actual results

See both Cura and CuraEngine as Intel apps

Expected results

If M1 supported it should state Apple instead of Intel

Checklist of files to include

• [ ] Log file
• [ ] Project file

Additional information & file uploads

[TheSin-]

this will be around for 2 months, Enjoy! https://file.io/4Ik2MmuM1H5G

Why was it deleted?

I'm guessing they don't want it posted.

If that is the case I apologize, I figured it's help out buy some times while it goes official and help find more issues. I just sliced something without issues!

[lantren]

I'm guessing they don't want it posted.

That was what I understood given the context. Thank you for your efforts. Well done.

[TheSin-]

see this script for build the apple dmg

https://github.com/Ultimaker/Cura/blob/main/packaging/MacOS/build_macos.py

and this workflow for inspiration how you can build the rest: https://github.com/Ultimaker/Cura/blob/main/.github/workflows/cura-installer.yml

I believe @Joeydelarago could help you out and tell you which environmental variables you need to set to notarize and sign the dmg or pkg

I'll just test a bit more, and if all is well I'll make PRs for it, it's such small changes. If there is anything else I can do to help out please let me know. It's the least I can do for this great project.

[TheSin-]

this will be around for 2 months, Enjoy! https://file.io/4Ik2MmuM1H5G

Why was it deleted?

If anyone has a good free service I'd be happy to upload it there so at least we can start testing it.

[jellespijker]

I will check if I can build it locally as well and we could then maybe host it in one of our cloud services.

but it might be somewhere in the end of the weekend beginnen of the next week that I actually have some time for this.

can you atleast post share the changes to the hash here?

[jellespijker]

which service did you use to share it btw? Strange that they deleted it

[TheSin-]

had to add a new has for cryptography==3.4.8

--- a/requirements.txt
+++ b/requirements.txt
@@ -35,7 +35,8 @@ certifi==2021.10.8 \
 cryptography==3.4.8; \
     --hash=sha256:a00cf305f07b26c351d8d4e1af84ad7501eca8a342dedf24a7acb0e7b7406e14 \
     --hash=sha256:3520667fda779eb788ea00080124875be18f2d8f0848ec00733c0ec3bb8219fc \
-    --hash=sha256:1eb7bb0df6f6f583dd8e054689def236255161ebbcf62b226454ab9ec663746b
+    --hash=sha256:1eb7bb0df6f6f583dd8e054689def236255161ebbcf62b226454ab9ec663746b \
+    --hash=sha256:f44d141b8c4ea5eb4dbc9b3ad992d45580c1d22bf5e24363f2fbf50c2d7ae8a7
 zeroconf==0.31.0 \
     --hash=sha256:53a180248471c6f81bd1fffcbce03ed93d7d8eaf10905c9121ac1ea996d19844 \
     --hash=sha256:5a468da018bc3f04bbce77ae247924d802df7aeb4c291bbbb5a9616d128800b0

this was the only hash changes.

When making the .app I had to modify the spec file perl -pi -e 's,x86_64,arm64,g' UltiMaker-Cura.spec and I had to manually copy a few files. I followed the logic from the .github/workflows/cura-installer.yml but I already had it built in venv so I modified as needed to get it built. That was really all I needed to do, I'm pretty sure if I worked at it I could build it as a Universal so both x86_64 and arm64 would be in the same build.

it was file.io, I just did a google for a free service since I don't often have the need to host files.

[TheSin-]

this looks like it might be the other patch place

https://github.com/Ultimaker/Cura/blob/main/conanfile.py#L256

could use uname -m there instead of hardcoding it

[jellespijker]

@TheSin- nice work!

I quickly applied your suggestions (slightly altered) see co-authored commits bfed341 and a235827

If these are indeed all the changes needed (didn't test this yet myself), it should be able to compile and build for the M1.

1. Change the arch=x86_44 to arch=armv8 in the default conan profile
2. Then execute execute the following steps:

   conan install cura/latest@ultimaker/testing  --build=missing --update -if cura_inst -g VirtualPythonEnv --json "cura_inst/conan_install_info.json"
   source cura_inst/bin/activate
   pyinstaller cura_inst/UltiMaker-Cura.spec

This should give you the standalone native compiled Cura version (with the latest commit from main). But keep in mind the above code and commits aren't tested yet.

See the conan docs for more info:

• https://docs.conan.io/1/systems_cross_building.html

[Joeydelarago]

Looks great @TheSin- 

I'll have a look at generating a build with our GitHub actions build system. Glad to hear you could find your way around our build system. I'll chat with the team about hosting some test builds.

[TheSin-]

I'll do a wipe and retest today if I have time and report back.

I cleared out ~/.local, ~/.conan, ~/Library/Python, hard reset the Cura repo, did a pull, reinstalled conan==1.56.0, re fetched the profiles, and I'm currently redoing the build with no mods ATM, I'll reply back once it's done.

[TheSin-]

Just to add it someplace this might be a good thing to follow https://github.com/conan-io/conan/issues/12667 if this gets sorted Cura could be built and released as universal2 instead of an x86 and arm64 release, keep the releases down.

Everything worked perfectly! The instructions where missing the openssl build and dylib copies from the workflow, but it built the app and I ran it without issues, did you want me to upload the dmg someplace?

[jellespijker]

the universal binaries would require additional changes in our custom build tools for the Python bindings with SIP

https://github.com/Ultimaker/conan-ultimaker-index/blob/main/recipes/pyprojecttoolchain/conanfile.py

https://github.com/Ultimaker/conan-ultimaker-index/tree/main/recipes/sipbuildtool

These changes, in the SIP build /pyprojecttoolchain , tend to grow fairly quickly in complexity since the Python build scripts that are called in the background tend not to do the linking correctly.

so beware here, be dragons

[TheSin-]

Oh absolutely, but it'd be really nice for future proofing the build process, though I'm not sure the effort would be worth it ATM, but it would be one build instead of 2 resource wise, and one release instead of 2 dmg files.

But I do agree it's not trivial and maybe not even worth looking into is conan won't support it. I'm just happy to have native, I ran Cura all night and printed 5 sliced projects from it, worked perfectly in everything I did. Solved all the issues I've been having since not being able to use Cura.

Bug thank you to your team for all the effort here. Man I missed Cura! If uploading this dmg to your team would help in any way so that they can look at it or analyze it, please let me know I'd be happy to help how ever I can.

[jellespijker]

and thank you for helping us out as well.

My manager (big Apple fanboy) gave me a big YES when I asked him if I could start discussing with IT how we can facilitate building the M1 natively.

[TheSin-]

that's great news. And I like your boss already ;). If there is anything else I can help with please feel free to reach out to me directly, I'm happy to help in any form.

And thanks for the learning fun with conan, I love learning new build systems, I actually really enjoyed conan.

[jellespijker]

⬆️ Tagging one of the Conan founders @memsharded because it is always nice to hear that people enjoy the product you made.

[imajes]

Thanks for the work @theSin-!! I got as far as the conan ctypes build issues and had to pause the work. Glad to see you got throught it --- amazing amazing work. :)

[memsharded]

Thanks very much @TheSin- for the kind words, and thanks @jellespijker for tagging.

Really happy to hear that, hearing things like this is really the reason we love open source and keep working so hard to continue improving (...talking about improving, keep tuned about Conan big news for tomorrow! 😄 )

[TheSin-]

well if that isn't for shadowing.... :D can't wait to hear

[jellespijker]

@TheSin- Currently building it locally on my M1, using LLVM clang (because Apple-clang is holding us back in many regards)

Had to change the following things so far:

default profile

[settings]
os=Macos
os_build=Macos
arch=armv8
arch_build=armv8
compiler=clang
compiler.version=15
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
[env]
CC=/opt/homebrew/opt/llvm/bin/clang
CXX=/opt/homebrew/opt/llvm/bin/clang++
LDFLAGS="-L/opt/homebrew/opt/llvm/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm/lib/c++ -L/opt/homebrew/opt/llvm/lib"
CPPFLAGS="-I/opt/homebrew/opt/llvm/include"

run the Conan install with:

conan install cura/latest@ultimaker/testing  --build=missing --update -if cura_inst -g VirtualPythonEnv --json "cura_inst/conan_install_info.json" --require-override=libffi/3.4.2@_/_

Notice the override of libffi, I had to change the minimum_required version in the package downloaded from conan-center-index in that recipe to 1.56.0 (1.57.0 currently doesn't work in our configuration)

But I still keep in running into the original issue, that is that I have to compile the wheel for script and for that to work it needs openblas

...
      WARNING: CMake Toolchain: Failed to determine CMake compilers state
      Run-time dependency openblas found: NO (tried pkgconfig, framework and cmake)
      Run-time dependency openblas found: NO (tried pkgconfig, framework and cmake)

      ../../scipy/meson.build:134:0: ERROR: Dependency "OpenBLAS" not found, tried pkgconfig, framework and cmake
...

Adding openblas/0.3.20 as a dependency in the conandat.yml of Cura seems to run into other problems:

-- Reading vars from /Users/j.spijker/.conan/data/openblas/0.3.20/_/_/build/1ac77434c4671b33f0e8271fc1d7db0c69af2b86/source_subfolder/kernel/x86_64/KERNEL...
-- Reading vars from /Users/j.spijker/.conan/data/openblas/0.3.20/_/_/build/1ac77434c4671b33f0e8271fc1d7db0c69af2b86/source_subfolder/kernel/x86_64/KERNEL.VORTEX...
CMake Error at source_subfolder/cmake/utils.cmake:23 (file):
  file STRINGS file
  "/Users/j.spijker/.conan/data/openblas/0.3.20/_/_/build/1ac77434c4671b33f0e8271fc1d7db0c69af2b86/source_subfolder/kernel/x86_64/KERNEL.VORTEX"
  cannot be read.
Call Stack (most recent call first):
  source_subfolder/kernel/CMakeLists.txt:13 (ParseMakefileVars)
  source_subfolder/kernel/CMakeLists.txt:1097 (build_core)

Adding the shared and dynamic_arch options seems to be the logical step here, since the file it complains about is in a folder called: `../x86_64/.. and I need the shared lib to link against the scipy Python module.

conan install cura/latest@ultimaker/testing  --build=missing --update -if cura_inst -g VirtualPythonEnv --json "cura_inst/conan_install_info.json" --require-override=libffi/3.4.2@_/_ -o openblas:shared=True -o openblas:dynamic_arch=True

This keeps tripping on assembly code specific to x86_64 architecture; This looks like a problem I'm not gonna solve after a work day of 10 hours while sitting on the couch at home. Since this involves diving in the Conan recipe and build scripts for openblas https://github.com/conan-io/conan-center-index/blob/master/recipes/openblas/all/conanfile.py

To make it compile on armv8.

Now we might also be helped already if someone else could build the wheel for Scipy making sure it works on the M1 ARM architecture for Python 3.10.4. Since that would allow us to handle Scipy the same way as we treat the Numpy+mkl Python package for Windows and store it in a pip Artifactory to be downloaded when installing the Virtual Environment.

But on a sad note we're there yet.

[jellespijker]

@memsharded looking forward to the news tomorrow.

[TheSin-]

@jellespijker what macOS version, Xcode version are you on? I assume you are on x86 cross compiling? Or do you have an Apple Silicon machine for testing?

yes conan need to be pinned to 1.56.0 this is very important

also remember I'm using fink over brew for all my depends including python3.9

what cmake do you have? This might be a cmake version thing.

i cmake 3.24.1-1 Cross-platform Make

If you'd like I could test with llvm, I was using apple-clang

my default profile is

[settings]
os=Macos
os_build=Macos
arch=armv8
arch_build=armv8
compiler=apple-clang
compiler.version=14
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
[env]

EDIT: nvm I see you said locally on your M1, so it's not a cross compile.

[TheSin-]

BTW here is a link to the dmg https://drive.google.com/file/d/1dp2u-Pm0yb8ORewTjKSkg5A_qOGZuI4Z/view?usp=share_link At least here you can have a look at it and try running it.

[jellespijker]

doing this completely on the M1 in the regular terminal, not the rosseta one.

no cross compiling going one

[TheSin-]

And for the MacOS and Xcode versions?

Also why no apple-clang I ran into no issues with it (or is a future issue?, unreleased code or something in the enterprise side?)

I have an M1 here I'm going to set it up to build just to make sure

[jellespijker]

Apple clang doesn’t even fully support C++14, and we are using C++20.

We had to write a lot of exceptions in the engine to make it work and enable threading on Mac and much more. Basically all the custom SIP and pyprojecttoolchain are huge work arounds just to get things working on Mac with Apple Clang and that took months and in my experience heavy customization is difficult to maintain and support for longer periods. So compiling with LLVM clang, gcc and MSVC is more sustainable in te future and less of a resource hog.

[jellespijker]

I did a clean install of everything all the build tools at the latest version.

The fact that you use the 3.9 Python version is an indication that you are not doing the complete build process and we need 3.10.4 on our other systems

[TheSin-]

I can test with 3.10 or even 3.11, I personally use 3.9 cause that is what debian stable runs and I need my system as close to debian stable as I can.

I just made sure I meat the minimums from your build page on everything.

I can also compile gcc12 and test with that if it helps, though I won't install brew, it's a mess and it will cause me grief on my system. I'm currently testing it on a clean M1 with 13.2 and Xcode 14. I just got fink installed with all the requirements, and installed conan, I'm about to start the build process now. This will be with apple-clang again though and it's just to verify.

[TheSin-]

This is the list from https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source my version for each is in front in bold.

13.2.1 macOS 10.15 or higher 14.2 xcode 11.4 or higher 14.0 apple-clang-9.0 or higher 3.9.12 Python 3.6 or higher 20.13.0 venv (Python) 6.7.7 sip (Python) 6.5.0 or higher 6.043.14043 altool 1.15.1 automake 3.24.1 CMake 3.23 or higher 1.11.0 Ninja 1.10 or higher 1.56.0 Conan 1.56.0

[jellespijker]

so what happens when you run:

conan install cura/latest@ultimaker/testing --build=missing --update -if cura_inst -g VirtualPythonEnv --json "cura_inst/conan_install_info.json" --require-override=libffi/3.4.2@_/_

it will probably fail with libffi, but then change the libffi recipe in Conan data to change minimum required version and run the above command again

[imajes]

Yep -- i had to change the libffi requirement, but it built just fine. I can't open it though as i'm having issues with my scipy being unable to install -- this is the same issue i had previously:

Traceback (most recent call last):
  File "/Users/james/src/3d/Cura/venv/lib/python3.10/site-packages/scipy/__init__.py", line 166, in <module>
    from scipy._lib._ccallback import LowLevelCallable
  File "/Users/james/src/3d/Cura/venv/lib/python3.10/site-packages/scipy/_lib/_ccallback.py", line 1, in <module>
    from . import _ccallback_c
  File "_ccallback_c.pyx", line 210, in init scipy._lib._ccallback_c
  File "/Users/james/.conan/data/cpython/3.10.4/_/_/package/a0335f0ac06cdedb0cd26cc9be90613dd131eac3/lib/python3.10/ctypes/__init__.py", line 8, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/james/src/3d/Cura/./cura_app.py", line 28, in <module>
    from cura.CrashHandler import CrashHandler
  File "/Users/james/src/3d/Cura/cura/CrashHandler.py", line 27, in <module>
    from UM.Application import Application
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Application.py", line 10, in <module>
    from UM.Controller import Controller
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Controller.py", line 3, in <module>
    from UM.Scene.Iterator.DepthFirstIterator import DepthFirstIterator
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Scene/Iterator/DepthFirstIterator.py", line 3, in <module>
    from UM.Scene.SceneNode import SceneNode
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Scene/SceneNode.py", line 14, in <module>
    from UM.Mesh.MeshBuilder import MeshBuilder
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Mesh/MeshBuilder.py", line 4, in <module>
    from UM.Mesh.MeshData import MeshData
  File "/Users/james/.conan/data/uranium/5.4.0-alpha+testing_11/ultimaker/testing/package/377c34c3d42b2857c2138cbdb0dea7862ba36d4e/site-packages/UM/Mesh/MeshData.py", line 16, in <module>
    import scipy.spatial
  File "/Users/james/src/3d/Cura/venv/lib/python3.10/site-packages/scipy/__init__.py", line 171, in <module>
    raise ImportError(msg) from e
ImportError: The `scipy` install you are using seems to be broken, (extension modules cannot be imported), please try reinstalling.```

[TheSin-]

you can download my dmg just to see that it does run for me. I'm on testing_15 though, not testing_11

my version is built using 3.10.4 as well, just not to install conan, I use 3.9 to install conan, then conan installs 3.10.4 via CPython and it uses that for the venv

$ ls -l cura_inst/bin/python*
lrwxr-xr-x 1 justin staff  10 Feb 21 09:05 cura_inst/bin/python -> python3.10
lrwxr-xr-x 1 justin staff  10 Feb 21 09:05 cura_inst/bin/python3 -> python3.10
lrwxr-xr-x 1 justin staff 108 Feb 21 09:05 cura_inst/bin/python3.10 -> /Users/justin/.conan/data/cpython/3.10.4/_/_/package/9ed83d5094eed6746ee64419036814b0c887de78/bin/python3.10

My M1 build is currently building tk and going strong

EDIT: NVM about the testing_!5 vs 11 thing I see that was for uranium not Cura, I'm still learning all that parts.

[TheSin-]

Looks like mine build and installs libffi@3.2.1, but I don't have to re issue a command so it must do it on it's own? I'll see if I can up the libffi version here, give me a bit to set that up

[~/.conan/data/libffi]$ ls
3.2.1

Can't do libffi 3.4.2 with conan 1.56 so I assume pyarcus will need to be updated as well since pyacrus/5.2.2 will fail with conan > 1.56.0

so in order to up libffi, conan will need to be upped and for that pyacrus will need to up upped, can't just do the one.

WARN: cpython/3.10.4: requirement libffi/3.2.1 overridden by pyarcus/5.2.2 to libffi/3.4.2 
libffi/3.4.2: Not found in local cache, looking in remotes...
libffi/3.4.2: Trying with 'cura'...
libffi/3.4.2: Trying with 'cura-ce'...
libffi/3.4.2: Trying with 'conan-center'...
Downloading conanmanifest.txt completed [0.50k]                                          
Downloading conanfile.py completed [7.19k]                                               
Downloading conan_export.tgz completed [0.37k]                                           
Decompressing conan_export.tgz completed [0.00k]                                         
libffi/3.4.2: Downloaded recipe revision d4b664e1917b631217a29948ee8175db

JSON file created at '/Users/justin/Devel/cvsroot/Cura/cura_inst/conan_install_info.json'
ERROR: libffi/3.4.2: Cannot load recipe.
Error loading conanfile at '/Users/justin/.conan/data/libffi/3.4.2/_/_/export/conanfile.py': Current Conan version (1.56.0) does not satisfy the defined one (>=1.57.0).

[TheSin-]

I updated conan to 1.57.0, and then forced libffi to 3.4.2 without issues.

libffi/3.4.2: Copied 1 file: LICENSE
libffi/3.4.2 package(): Packaged 1 file: LICENSE
libffi/3.4.2 package(): Packaged 2 '.h' files: ffitarget.h, ffi.h
libffi/3.4.2 package(): Packaged 1 '.a' file: libffi.a
libffi/3.4.2: Package '240c2182163325b213ca6886a7614c8ed2bf1738' created
libffi/3.4.2: Created package revision 4ea0503720660431c8d8715184cd7ae7
libxcrypt/4.4.25: Already installed!

but I'm sure pyarcus will fail once it gets there now.

EDIT: As suspected

pyarcus/5.2.2: Aggregating env generators
pyarcus/5.2.2: Calling build()
pyarcus/5.2.2: 
pyarcus/5.2.2: ERROR: Package '855146759e8d69bfd4b652423771d45ce62c6856' build failed
pyarcus/5.2.2: WARN: Build folder /Users/justin/.conan/data/pyarcus/5.2.2/_/_/build/855146759e8d69bfd4b652423771d45ce62c6856/build/Release

JSON file created at '/Users/justin/Devel/cvsroot/Cura/cura_inst/conan_install_info.json'
ERROR: pyarcus/5.2.2: Error in build() method, line 103
    cmake = CMake(self)
    FileNotFoundError: [Errno 2] No such file or directory: '/Users/justin/.conan/data/pyarcus/5.2.2/_/_/build/855146759e8d69bfd4b652423771d45ce62c6856/build/Release/generators/CMakePresets.json'

[jellespijker]

the --require-overide=libffi/.... command during the conan install is important that will grab another version you are using now and that should override all the requires of libffi needed in the chain.

after that just change the minimum required conan version in the recipe, which can be found in ~./conan/data/libffi/......./export/conanfile.py and run the conan install ... again.

could you double check if you have system version of openblas somewhere on your path?

[TheSin-]

I do not have open bias installed, I only use fink to not pollute my system PATH and it doesn't have openbias.

But there must be a reason that libffi required conan > 1.57.0 which is likely what you are running in to. it must depends on that breaking change that happen in 1.57.0

[jellespijker]

just change the minimum required conan version in the recipe which can be found in ~./conan/data/libffi/......./export/conanfile.py and run the conan install ... again. you then basically editing this line in your local cache https://github.com/conan-io/conan-center-index/blob/a5556a94693040e44c12beb802e2beed2e3dc022/recipes/libffi/all/conanfile.py#L13

could you double check if you have system version of openblas somewhere on your path?

[jellespijker]

I will update our remote Artifactory with the changed version tomorrow

[TheSin-]

Since I had libffi built, I reinstalled conan 1.56.0, I think modified that file so it wouldn't rebuild libffi, and it just continued on, so this build will be using libffi 3.4.2, it's almost done now. But that's an automation nightmare.

[TheSin-]

built on clean M1, no issues, and running. Of course that is the current git so libffi 3.2.1

[TheSin-]

@jellespijker where would OpenBias be built/install if the build system was doing it? I can't seem to find mention of it any place on my system.

NVM I see it's an L not an I

$ find . -iname \*openblas\*
./cura_inst/lib/python3.10/site-packages/numpy/.dylibs/libopenblas.0.dylib
./cura_inst/lib/python3.10/site-packages/scipy/.dylibs/libopenblas.0.dylib
./dist/UltiMaker-Cura/libopenblas.0.dylib
./dist/UltiMaker Cura.app/Contents/MacOS/libopenblas.0.dylib
./dist/UltiMaker Cura.app/Contents/Frameworks/libopenblas.0.dylib

$ ls -l cura_inst/lib/python3.10/site-packages/numpy/.dylibs/libopenblas.0.dylib
-rwxr-xr-x 1 justin staff 20935616 Feb 21 09:05 cura_inst/lib/python3.10/site-packages/numpy/.dylibs/libopenblas.0.dylib

$ otool -L cura_inst/lib/python3.10/site-packages/numpy/.dylibs/libopenblas.0.dylib
cura_inst/lib/python3.10/site-packages/numpy/.dylibs/libopenblas.0.dylib:
    /DLC/numpy/.dylibs/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)

[jellespijker]

don't known where openblas might be installed on your system.

minimum required conan version for this recipe could be lowered, it probably has the 1.57.0 value because it has been recently updated and that is the latest CCI CI version the use

[jellespijker]

could you check if you have the Fortran compiler installed. Scipy (and openblas) need that compiler for optimization.l maybe you don't have it and then certain features are disabled. Btw not an option for us to disable that since we need those optimization for the speed on the front-end. Python is slow enough as is.

https://docs.scipy.org/doc/scipy/dev/contributor/osx.html#build-osx

[TheSin-]

I checked I don't have openblas or spicy installed outside of this build. now that I'm looking for the right lib name ;)

And the clean build I just did on the M1 for sure didn't have it installed as it had nothing installed at all

[imajes]

@TheSin- have you been getting any issues with _ctypes and scipy ?

[TheSin-]

@TheSin- have you been getting any issues with _ctypes and scipy ?

I have not at all. On both systems. I ran into the pyarcus issue cause I installed latest conan originally.

[imajes]

odd. i'm purging my python install to see if i can fix that -- internet tells me that it's likely due to libffi not being correct. Odd, otherwise i have a clean build.

[TheSin-]

let me know if I can help @imajes

Not sure if it helps but I do not have rosetta installed at all on both systems I tested it with. Which means I have no mix of builds at all.

[jellespijker]

so adding: CMAKE_APPLE_SILICON_PROCESSOR=arm64 to the [env] section of the default profile will build openblas for the arm architecture, except now I get a linker error at the end. Those a often indication that I need to clean my cache from old build artefacts

https://cmake.org/cmake/help/latest/envvar/CMAKE_APPLE_SILICON_PROCESSOR.html#envvar:CMAKE_APPLE_SILICON_PROCESSOR