Cura 4.6 not launching in macOS 11 Big Sur beta
Application version
4.6
Platform
macOS 11 Beta
Printer
not relevant
Reproduction steps
Launch Cura
Reinstall Cura and launch Cura
Screenshot(s)
not relevant
Actual results
Cura in not launching and is just quitting.
Expected results
Cura should launch and show a regular Cura window
Project file
not applicable
Log file
Log file is empty, App has not been launched to a state where it can write logs.
Additional information
Launching Cura does not work.
Right-clicking on the Cura app to open it and bypassing the file quarantine doesn't work either.
Removing the quarantine flag doesn't help either.
The macOS log system shows entries regarding Cura:
com.apple.xpc.launchd[1] (application.nl.ultimaker.cura.24069125.24069132[10009]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1]: Coalition Cache Hit: app
Sandbox: logd_helper(119) deny(1) file-read-data /Applications/Ultimaker Cura.app/Contents/MacOS/libgcc_s.1.dylib
[app
TimoLemburg
All 79 comments
i do have the same problem. Also macOS 11 Dev Beta. Neither older Cura or newest Cura work.
davidkrammer
on 24 Jun 2020
Same problem
jeffreyspaceboy
on 24 Jun 2020
I don't think the newer Macs support the version of Qt we're using, which we are stuck on ironically, because of slightly older Macs.
This is going to require some work and digging in the DevOps part in any case.
rburema
on 25 Jun 2020
Could you check the system log whether you see messages from amfid when launching Cura? I've seen this problem with other apps and it was related to code signing.
IngmarStein
on 25 Jun 2020
If it's the code signing, that would be great, since that is already high up on our backlog. So we would really appreciate it if someone can confirm that for us!
nallath
on 25 Jun 2020
Where can i view get the logs for that? Then i would post them here.
davidkrammer
on 25 Jun 2020
@davidkrammer You can find the logfile next to the .cfg file described here: https://github.com/Ultimaker/Cura/wiki/Cura-Preferences-and-Settings-Locations
rburema
on 25 Jun 2020
@rburema, that is not the logfile he is asking for.
I think the best place to look for reasons the app does not start up (to the point that is does not even start logging) is in Console.app.
fieldOfView
on 25 Jun 2020
I am seeing the following amfid entries in the log when I launch Cura:
standard 17:46:55.226214+0200 mDNSResponder [R4299] DNSServiceCreateDelegateConnection START PID115
standard 17:46:55.226355+0200 mDNSResponder [R4300] DNSServiceGetAddrInfo(C000D000, 0, 0,
standard 17:46:55.266771+0200 mDNSResponder [R4299] DNSServiceCreateConnection STOP PID115
standard 17:46:55.266807+0200 mDNSResponder [R4300] DNSServiceGetAddrInfo(
It doesn't seem to be the issue.
Additionally I looked for the App Notarization (which is missing in Cura and should be one of the new must haves), but I have other Apps that are not notarized which are also still running.
TimoLemburg
on 25 Jun 2020
Here is what I could fetch in the console when starting Cura. I have removed the noise from other processes.
TimoLemburg
on 25 Jun 2020
Could you check the system log whether you see messages from amfid when launching Cura? I've seen this problem with other apps and it was related to code signing.
default 15:40:57.289305-0500 mDNSResponder [R161518] DNSServiceCreateDelegateConnection START PID[120](amfid)
default 15:40:57.289395-0500 mDNSResponder [R161519] DNSServiceGetAddrInfo(C000D000, 0, 0, <mask.hash: '6Cur6O9CppaeO/S6CYxFdw=='>) START PID[120](amfid)
default 15:40:57.290179-0500 mDNSResponder [R161518] DNSServiceCreateConnection STOP PID[120](amfid)
default 15:40:57.290204-0500 mDNSResponder [R161519] DNSServiceGetAddrInfo(<mask.hash: 'nlcB66KUburjY4sSDH0j2Q=='>) STOP PID[120](amfid)
That's all that showed up regarding amfid when I tried to launch Cura.
Everything in the system log with "cura" in the search...
default 15:40:57.277131-0500 runningboardd Executing launch request for app<application.nl.ultimaker.cura.61963919.61963926(501)> (LS launch nl.ultimaker.cura)
default 15:40:57.277178-0500 runningboardd Creating and launching job for: app<application.nl.ultimaker.cura.61963919.61963926(501)>
default 15:40:57.336447-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] This process will not be managed.
default 15:40:57.336477-0500 runningboardd Now tracking process: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:57.336528-0500 runningboardd Using default underlying assertion for app: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:57.336559-0500 runningboardd Calculated state for app<application.nl.ultimaker.cura.61963919.61963926(501)>: running-suspended (role: None)
default 15:40:57.336600-0500 runningboardd Acquiring assertion targeting app<application.nl.ultimaker.cura.61963919.61963926(501)> from originator [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] with description <RBSAssertionDescriptor| "RB Underlying Assertion" ID:161-161-42591 target:30024 attributes:[
<RBSDomainAttribute| domain:"com.apple.underlying" name:"defaultUnderlyingAppAssertion" sourceEnvironment:"(null)">,
<RBSAcquisitionCompletionAttribute| policy:AfterApplication>
]>
default 15:40:57.336702-0500 runningboardd Assertion 161-161-42591 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>) will be created as active
default 15:40:57.337111-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] reported to RB as running
default 15:40:57.337610-0500 runningboardd Calculated state for app<application.nl.ultimaker.cura.61963919.61963926(501)>: running-suspended (role: None)
default 15:40:57.337869-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring jetsam update because this process is not memory-managed
default 15:40:57.338088-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring suspend because this process is not lifecycle managed
default 15:40:57.338332-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Set darwin role to: None
default 15:40:57.339669-0500 loginwindow -[PersistentAppsSupport applicationReady:] | App: Ultimaker Cura, ready, updating active tracking timer
default 15:40:57.338601-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring GPU update because this process is not GPU managed
default 15:40:57.339744-0500 loginwindow -[ApplicationManager checkInAppContext:eventData:] | ApplicationManager: Checked in app : Ultimaker Cura
default 15:40:57.339412-0500 runningboardd Acquiring assertion targeting app<application.nl.ultimaker.cura.61963919.61963926(501)> from originator [daemon<com.apple.coreservices.launchservicesd>:93] with description <RBSAssertionDescriptor| "foregroundApp:30024" ID:161-93-42592 target:30024 attributes:[
<RBSDomainAttribute| domain:"com.apple.launchservicesd" name:"RoleUserInteractiveNonFocal" sourceEnvironment:"(null)">
]>
default 15:40:57.339596-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Skipping AppNap state - not lifecycle managed
default 15:40:57.340130-0500 runningboardd Assertion 161-93-42592 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>) will be created as active
default 15:40:57.342725-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring jetsam update because this process is not memory-managed
default 15:40:57.342982-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring suspend because this process is not lifecycle managed
default 15:40:57.343221-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Set darwin role to: UserInteractiveNonFocal
default 15:40:57.343426-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Ignoring GPU update because this process is not GPU managed
default 15:40:57.342622-0500 runningboardd Acquiring assertion targeting app<application.nl.ultimaker.cura.61963919.61963926(501)> from originator [daemon<com.apple.coreservices.launchservicesd>:93] with description <RBSAssertionDescriptor| "foregroundApp:30024" ID:161-93-42593 target:30024 attributes:[
<RBSDomainAttribute| domain:"com.apple.launchservicesd" name:"RoleUserInteractiveNonFocal" sourceEnvironment:"(null)">
]>
default 15:40:57.343920-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] Skipping AppNap state - not lifecycle managed
default 15:40:57.344086-0500 runningboardd Assertion 161-93-42593 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>) will be created as active
default 15:40:57.342613-0500 runningboardd Calculated state for app<application.nl.ultimaker.cura.61963919.61963926(501)>: running-active (role: UserInteractiveNonFocal)
default 15:40:57.345685-0500 runningboardd Invalidating assertion 161-93-42592 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>) from originator [daemon<com.apple.coreservices.launchservicesd>:93]
default 15:40:57.347199-0500 runningboardd Finished acquiring assertion 161-161-42591 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>)
default 15:40:57.347281-0500 runningboardd Successfully acquired underlying assertion for [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:57.347414-0500 runningboardd Finished acquiring assertion 161-93-42592 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>)
default 15:40:57.347508-0500 runningboardd Finished acquiring assertion 161-93-42593 (target:app<application.nl.ultimaker.cura.61963919.61963926(501)>)
default 15:40:57.356347-0500 distnoted register name: com.apple.sharedfilelist.change object: com.apple.LSSharedFileList.ApplicationRecentDocuments/nl.ultimaker.cura token: ad00000083 pid: 460
error 15:40:58.199842-0500 kernel Sandbox: logd_helper(254) deny(1) file-read-data /Applications/Ultimaker Cura.app/Contents/MacOS/libgcc_s.1.dylib
default 15:40:58.521302-0500 runningboardd [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024] termination reported by launchd (0, 0, 256)
default 15:40:58.521383-0500 runningboardd Removing process: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:58.521775-0500 runningboardd Removing launch job for: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:58.522207-0500 runningboardd Removed job for [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:58.522233-0500 runningboardd Removing assertions for terminated process: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:58.522439-0500 runningboardd Calculated state for app<application.nl.ultimaker.cura.61963919.61963926(501)>: none (role: None)
default 15:40:58.539630-0500 runningboardd Calculated state for app<application.nl.ultimaker.cura.61963919.61963926(501)>: none (role: None)
default 15:40:58.540591-0500 launchservicesd Hit the server for a process handle 282e047b00007548 that resolved to: [app<application.nl.ultimaker.cura.61963919.61963926(501)>:30024]
default 15:40:58.542186-0500 loginwindow -[PersistentAppsSupport applicationQuit:] | for app:Ultimaker Cura, _appTrackingState = 2
default 15:40:58.542220-0500 loginwindow -[PersistentAppsSupport applicationQuit:] | App: Ultimaker Cura, quit, updating active tracking timer
I checked the cura.log and it hasn't been modified since I installed Big Sur, so the app never makes it far enough to actually writer entries to the file. I renamed it to even see if a new one would be created and it wasn't.
Let me know if I can provide any more info....
Thanks
Ross
rosskinard
on 26 Jun 2020
It may have been a red herring then. In the other app's case, I saw the following items in the log
standard 00:16:59.865739+0200 amfid Failure getting cert chain.
standard 00:16:59.865783+0200 amfid Requirements for restricted entitlements failed to validate, error -67688, requirements: '<private>', error: (null)
standard 00:16:59.865802+0200 amfid Restricted entitlements not validated, bailing out. Error: (null)
before it ends in a No architectures specified in launch archictectures similar to Cura on Big Sur.
IngmarStein
on 27 Jun 2020
+1 with this issue. I've attached my relevant logs from Console.app
christopher-wong
on 27 Jun 2020
I retrieved the actual Cura stderr.log from ~/Library/Logs/Cura (stdout.log is empty).
Excerpt below. It looks like there's a problem actually loading shapely, a dependency of Cura's. shapely uses ctypes to load native libraries it needs, and ctypes is struggling (seems similar to this StackOverflow post). Not sure how to address this, but hope this provides a little more context on what seems to be the root cause here.
Error in sys.excepthook:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 697, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/CuraApplication.py", line 51, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/Arranging/Arrange.py", line 7, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/Polygon.py", line 10, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/ShapelyUtil.py", line 6, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/__init__.py", line 4, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/base.py", line 17, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/coords.py", line 8, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 113, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 56, in load_dll
OSError: Could not find lib c or load any of its variants [].
michaelrcarroll
on 27 Jun 2020
Same issue here
Guilouz
on 29 Jun 2020
I have a problem.
psterba
on 29 Jun 2020
Same thing here
elliottxharris
on 30 Jun 2020
Still an issue on Beta 2
hywel-evans
on 8 Jul 2020
Still an issue on Beta 2
Yeah this likely won't get fixed in an OS update, because Big Sur changes the way software is allowed to look for library paths.
jarinudom
on 8 Jul 2020
Still an issue on Beta 2
Yeah this likely won't get fixed in an OS update, because Big Sur changes the way software is allowed to look for library paths.
When someone have something to test let me know... Thanks.
edvavi
on 10 Jul 2020
Anyone tried to fix this?
I am working on a fix, but I am not able to compile Cura on MacOS 11 Beta 2.
Always exiting with "ImportError: No module named 'PyQt5.QtWidgets'" - even if simple Testcode including QtWidgets is working.
It would be cool, if anyone is able to get this tool running - as it is a public beta since a few days I guess we will have much more people trying to use Cura on Big Sur.
gunterthomas
on 12 Jul 2020
From what I have read about this problem, the fix needs to be in Python. Whether that fix gets backported to the the version of Python that is used by UM is another matter.
smartavionics
on 12 Jul 2020
This one sounds pretty bad....
So no way to fix this? Well ... any source to check to get some updates on this problem? Or do we have to sit here and wait?
gunterthomas
on 13 Jul 2020
This is why I am of the opinion that Apple has an undying hatred for software developers. I mean, seriously, why the hell would you suddenly change the way that library path resolving works?
I don't really know if there is something we can do about this right now.
nallath
on 13 Jul 2020
This is why I am of the opinion that Apple has an undying hatred for software developers. I mean, seriously, why the hell would you suddenly change the way that library path resolving works?
You do know that Big Sur is a major release of MacOS (and not just a 10.x release)? Last time that happened was in 2001.
If you had to do a breaking change, what better time (seen from a software development perspective) to do it with a major release? I could see what you would mean if it was a minor release (like 10.16).
This is a (early) preview, that is under a month old, of what's coming, and not a stable release that have been out for years. You can't really blame Apple for you being trigger-happy for installing experimental software on your production machine.
Sorry for being so direct. But relax, things will get fixed at some point! - Or downgrade back to MacOS Catalina!
PelleRavn
on 13 Jul 2020
It would be the case if this was the first time that Apple pulled something like this. Unfortunately, it's not. OSX is by far the hardest OS for us to support (and keep supporting). This is just another thing on the list that makes it so.
I'm personally on Fedora, so this change doesn't affect me at all (apart from having to fix it some day ;))
nallath
on 13 Jul 2020
We're going to (have to) fix this, but there's a lot of hoops to jump through. Not the least of them is that it's extremely hard to get a virtualised environment for MacOS. And there's the hoop that we have to change our existing public keys with Apple in order to use the new signing system, but this needs re-verification and that takes a while.
For the particular issue that @michaelrcarroll posted an error for, it seems that @guntherthomas found a solution for that here: https://github.com/Ultimaker/cura-build/issues/242
Hopefully we can just apply the same change to our build system and it'll be fixed then.
Ghostkeeper
on 14 Jul 2020
Okay, maybe I didn't catch a thing, but why is it extremely hard to get macOS virtualised? I have been running ESXi, Parallels, VMWare Fusion and VMWare Fusion Pro as well as Virtual Box with macOS. The catch is of course that you need a Mac in the first place to run those platforms on them.
I am working in macOS Client Designer and we use VMWare Fusion Pro for all our Mac testing.
TimoLemburg
on 14 Jul 2020
I have built a MacOS release of my Cura that incorporates the tweak to geos.py that is meant to fix this crash. So if someone could install the 20200715 release on Bug Sir and report back, it would be useful. My releases can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file before using.
smartavionics
on 15 Jul 2020
I tried your release and it starts (after getting the quarantine bypassed), launches and is using one processor core at full load. No start-up windows shows up and Cura is not reacting anymore (according to Activity Monitor). Activity Monitor also show increasing use or virtual memory, I stopped if after some minutes and about 80GB virtual memory usage.
TimoLemburg
on 15 Jul 2020
Analyse von „Ultimaker Cura“.txt
Here is the Activity Monitor analysis
TimoLemburg
on 15 Jul 2020
Thanks for trying it. That monitor file doesn't mean much to me, perhaps someone else can glean something useful from it.
Could you please provide the cura.log file? There may be something useful in there and also if there is a stderr.log file, provide that. Thanks.
smartavionics
on 15 Jul 2020
In my User Library there are only two empty log files for stderr and stdout, nothing else. Sorry, forgot to mention that.
TimoLemburg
on 15 Jul 2020
OK.
smartavionics
on 15 Jul 2020
The catch is of course that you need a Mac in the first place to run those platforms on them.
... and therein lies the problem. Since we want to have all our (build) servers remote & do not want to be tied to a specific physical hardware item, which can get damaged, lost, stolen, suddenly stop working for an unknown reason, etc.
rburema
on 15 Jul 2020
When I tried the build @smartavionics provided, It didn't work for me either. Same symptoms as reported by @TimoLemburg, and still doesn't start far enough to create a log file.
gothickitty93
on 15 Jul 2020
In my User Library there are only two empty log files for stderr and stdout, nothing else. Sorry, forgot to mention that.
So that means that some Python code does get executed. It's a matter of figuring out where it's freezing.
Ghostkeeper
on 16 Jul 2020
If you need someone to test things on the latest Beta, hit me up.
niklasarnitz
on 16 Jul 2020
These are my log files I get when opening Cura (just for more context):
stderr.log
Error in sys.excepthook:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 697, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/CuraApplication.py", line 51, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/Arranging/Arrange.py", line 7, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/Polygon.py", line 10, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/ShapelyUtil.py", line 6, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/__init__.py", line 4, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/base.py", line 17, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/coords.py", line 8, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 113, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 56, in load_dll
OSError: Could not find lib c or load any of its variants [].
Original exception was:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/__startup__.py", line 12, in <module>
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/Console.py", line 21, in <module>
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Users/ultimaker/build/4.6/build/inst/bin/cura_app.py", line 191, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/CuraApplication.py", line 51, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/cura/Arranging/Arrange.py", line 7, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/Polygon.py", line 10, in <module>
File "/Users/ultimaker/build/4.6/build/inst/lib/python3.5/site-packages/UM/Math/ShapelyUtil.py", line 6, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/__init__.py", line 4, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geometry/base.py", line 17, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/coords.py", line 8, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 113, in <module>
File "/Users/ultimaker/build/env/4.6/inst/lib/python3.5/site-packages/shapely/geos.py", line 56, in load_dll
OSError: Could not find lib c or load any of its variants [].
It seems like, Apple is still mapping libraries to paths, but has changed the way they do this: https://stackoverflow.com/questions/62587131/macos-big-sur-python-ctypes-find-library-does-not-find-libraries-ssl-corefou
niklasarnitz
on 16 Jul 2020
Okay, this should be addressed in the next python release: https://bugs.python.org/issue41100
niklasarnitz
on 16 Jul 2020
Python 3.8.4 is on Homebrew now, and based on the changelog it looks like it should fix the issue. Is there a way to get Cura to use the Homebrew python instead of the one bundled in the .app?
jarinudom
on 17 Jul 2020
3.8.4 doesn't include the fix, but I managed to get Cura running with 3.8.4 and some changes to find_library and libArcus (sip is now PyQt5.sip) so that's something I suppose.
abrmecom
on 17 Jul 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
abrmecom
on 17 Jul 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
Worked for me on Beta 2...dropped that file in and it launched. I haven't put it through any paces but it does launch now. And I didn't move the geos.pyc file, I just added the geos.py file alongside it.
rosskinard
on 17 Jul 2020
Thanks @abrmecom. That fix seemed to work for me as well. I'll report back if anything breaks when I have more time to test.
gothickitty93
on 17 Jul 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
Thanks, that works for me (Big Sur beta 2).
xiujunma
on 17 Jul 2020
Same here with the standard Cura 4.6.1.
TimoLemburg
on 17 Jul 2020
I just created a PR over at shapely. Maybe they'll include the fix in their latest release.
niklasarnitz
on 17 Jul 2020
It’s not really a workable patch, more a quick hack to get cura running on the beta. The updates to python will fix the issue when they arrive so i doubt Shapely will want to change anything, but UM may need to do something if they stick with older python builds.
abrmecom
on 17 Jul 2020
A screenshot of the 4.6.2 download with patch (left) vs locally compiled with Qt5 and Py 3.8.4 etc. Surprised the download looks so blurry, but I guess there is more to do than a simple Big Sur workaround. Also notice the title bar colour (I use dark mode).
abrmecom
on 17 Jul 2020
it does work!!!
edvavi
on 18 Jul 2020
works like a charm to me. Thanks!!!!
On Thu, Jul 16, 2020 at 10:59 PM Xiujun Ma notifications@github.com wrote:
If anyone is willing to try, you could delete (or safely move)
/Applications/Ultimaker
Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included
geos.py file in the same directory. Let me know how you get on.geos.py.gz https://github.com/Ultimaker/Cura/files/4935355/geos.py.gz
Thanks, that works for me (Big Sur beta 2).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/7970#issuecomment-659807753,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2KRR74PSXF4RR7QORNEE3R365APANCNFSM4OGSGJLA
.
edvavi
on 18 Jul 2020
A screenshot of the 4.6.2 download with patch (left) vs locally compiled with Qt5 and Py 3.8.4 etc. Surprised the download looks so blurry, but I guess there is more to do than a simple Big Sur workaround. Also notice the title bar colour (I use dark mode).
That may be because of a different version of Qt? We're using 5.10.2 in our builds. It works with newer versions of Qt (tested up to 5.14) but things like pixel alignment are sometimes different, causing this sort of issue. On Linux there is also the issue that the AppImage includes the font renderer, which makes it look different if you're running locally and using a different font renderer, but I don't know if that is a thing on MacOS.
Ghostkeeper
on 20 Jul 2020
I'll see whether we can merge that patch in (and what even changed between them). If that's acceptable, I think we'd post a MacOS build here to have you guys test it, because we don't have a computer with Big Sur to test on at the moment.
Ghostkeeper
on 20 Jul 2020
We could also consider forking Shapely and applying the changes there.
nallath
on 20 Jul 2020
You can simply clone Shapely - but I would suggest to create a Pull Request (which is already done -- https://github.com/Toblerity/Shapely/pull/947) and fix the broken parts, so it appears in shapely within the next release.
I would like to help with things here, but I am not deep enough into this whole ecosystem in python as I am (to my shame) working on the php site.
Seems to me like the PR needs some rework to be done (integration-/buildpipelines fail).
gunterthomas
on 22 Jul 2020
But I would suggest to create a Pull Request (which is already done -- Toblerity/Shapely#947) and fix the broken parts, so it appears in shapely within the next release.
I agree it's a bit better, but it also means that we have to upgrade the version of shapely that we use. Since there are more changes since then, it would require a fair amount of extra testing on our side.
nallath
on 23 Jul 2020
We'll leave the pull request to the already existing one. No sense in making a second one with the same contents. I agree that it's preferable as long as we can update safely, and in the past we've created such pull requests to fix issues we had with our dependencies.
For our build system we can use a fork from the correct tag, or apply a patch file like we do to Qt to repair their file dialogues. That way we don't need to upgrade if it's unsafe, and we don't need to wait for that fix to be published.
Ghostkeeper
on 23 Jul 2020
Just installed the Big Sur public beta 1 and had the same problem. Your geos.py fix worked like a charm. Thanks so much!
drelich
on 8 Aug 2020
Excellent, Cura opens now thanks to @xiujunma
warst
on 9 Aug 2020
Amazing Fix! Can we please get this added to the real Cura install? Big Sur will be launching in 22-ish Days
ckizer
on 10 Aug 2020
Big Sur won’t be out until probably October. Every year for the past few it’s been late September to late October with about 9-11 beta builds before release. Not sure where you got that info from. Beta 4 introduced a lot of kernel panics on my system and quite a few people I know, so it’s nowhere near ready for a GM-candidate, much less actual release.
Sent from my iPhone
On Aug 10, 2020, at 2:51 PM, Court K notifications@github.com wrote:

Amazing Fix! Can we please get this added to the real Cura install? Big Sur will be launching in 22-ish Days—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
rosskinard
on 10 Aug 2020
The geos.pyc>geos.py change worked for me as well on Public Beta 1 and Cura 4.6.1
tideline3d
on 10 Aug 2020
Same, works just fine on V11.0 Beta (20A5343i)
hywel-evans
on 10 Aug 2020
Can anyone write me the installation procedure? Thank you
psterba
on 10 Aug 2020
Its in this thread above...
hywel-evans
on 10 Aug 2020
It worked for me but I had to do xattr -cr ***cura*** from terminal (build 20A5343i)
EnricoBara
on 11 Aug 2020
You might have noticed that we couldn't get this done for _the beta_ of 4.7, but we're still trying to get it to work for the actual release.
In that light, we _think_ we might've a temporary* fix for the build environment (based on @niklasarnitz 's patch, which was in turn based on @abrmecom 's observation).
So... anyone willing to test that hypothesis with this build?. Link goes to WeTransfer. Based on the current bleeding edge build (instead of 4.7, I'll update the build env. for that version once I get confirmation that this works), so beware of bugs & the like!
*) Temporary, because we should of course update shapely once they accept the patch or otherwise fix it. But that's something for 4.8 since they're sceptical about the current incarnation of the patch.
rburema
on 12 Aug 2020
So... anyone willing to test that hypothesis with this build?. Link goes to WeTransfer. Based on the current bleeding edge build (instead of 4.7, I'll update the build env. for that version once I get confirmation that this works), so beware of bugs & the like!
Seems to run anyway ... testing a bit more now.
abrmecom
on 12 Aug 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
Thanks mate that worked for me.
ryanmichaeljames
on 16 Aug 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
Thanks, that works for me (Big Sur beta 4 / macOS 11.0 (20A5343i)).
drwaky
on 16 Aug 2020
Should be fixed for 4.7 stable. Although it's patched in a bit of an ugly way until Shapely has this in a stable version.
Ghostkeeper
on 17 Aug 2020
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
This worked for me, running Cura 4.6.1. All I did was change 'geos.pyc' to '_geos.pyc' and drang n drop the geos.py file in place.
DDeFilippis
on 23 Nov 2020
Cura 4.8 works fine in Big Sur 11.0.1 release...also works in Big Sur 11.1 beta.
rosskinard
on 23 Nov 2020
And Cura 4.8 runs flawless on M1 processors.
Von meinem iPad gesendet
Am 23.11.2020 um 22:47 schrieb Ross Kinard notifications@github.com:

Cura 4.8 works fine in Big Sur 11.0.1 release...also works in Big Sur 11.1 beta.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
TimoLemburg
on 24 Nov 2020
Should be fixed for 4.7 stable. Although it's patched in a bit of an ugly way until Shapely has this in a stable version.
@Ghostkeeper Could I ask where is a commit containing this patch? I'm working on ealier version of Cura, but i need this fix desperatly. Is it in _cura-build_ repo? Best regards.
ThudPoland
on 24 Nov 2020
I'm running Cura 4.8 on a Mac Mini M1, Big Sur 11.0.1. While Cura starts and works as it should, rotating the view while the model is selected is a choppy experience. Are you also experiencing this, @TimoLemburg, or is there something I can do to alleviate this? (apart from deselecting the model, obviously :) )
westmark
on 27 Nov 2020
@evtrados How was this patch applied in our build system? I can't find it either.
Ghostkeeper
on 27 Nov 2020
Related issues
dstulken
·
3Comments
mnswamp1
·
3Comments
DmitryBychkov
·
3Comments
StanislavJochman
·
3Comments
jellewie
·
3Comments
Most helpful comment
If anyone is willing to try, you could delete (or safely move) /Applications/Ultimaker Cura.app/Contents/MacOS/lib/python3.5/shapely/geos.pyc and add the included geos.py file in the same directory. Let me know how you get on.
geos.py.gz