[BUG] UVtools 3.0.0 - arm build not functional #431
Comments
|
For thoroughness, have just tried it on a second M1 machine - same result unfortunately. |
|
Yes i know. See related here: #187 To run via |
|
Ah, ok sorry - I thought #187 was just the previous feature request for the arm build. Regardless, congrats on releasing v3 though - you must be exhausted! |
It is. But problem was also spoted while i send some test builds there.
I really don't know where to start, i tried multiple things but sending packages for each try is painfull, i would need some remote access to an M1 to accelerate this and dump everything i can try.
I had it on hold for some days by now. But not worth to keep it unreleased because of this situation |
|
I have an update for you - might help, might make things worse! (let me know if you'd prefer me to post this in 187 instead)... This is what I get when running 3.0.0 via sh method Failed to load /UVtools.app/Contents/MacOS/libhostpolicy.dylib, error: dlopen(/UVtools.app/Contents/MacOS/libhostpolicy.dylib, 0x0001): tried: '/UVtools.app/Contents/MacOS/libhostpolicy.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')) |
We can keep this thread as #187 was about the arm request and titled as such.
I don't know details about @aaaldo managed to run it via sh, but that error is strange, telling it's arm64 but need x64? |
|
I thought the same thing - bit of an odd error on an m1 mac. Anyway, the second m1 I've just tried it on (with a lot less libs installed on it), the sh script doesn't run at all as it can't find dotnet (line 3 of uvtools.sh). I just installed dotnet via brew and got this fairly horrendous error! UVtools.app/Contents/MacOS/UVtools.sh: line 3: 46221 Killed: 9 ./UVtools |
You dont need install dotnet since it's included on package. But if you do you need the 6.0.3. About libcvextern thats a common error when you missing any dependency. brew install cmake ffmpeg@4
brew link ffmpeg@4Reboot and retry |
dotnet definitely wasn't being picked up until I installed it via brew. Slight improvement though - both machines are now identically producing that longer error message re libcvextern - the libhost error went away after I updated dotnet to latest version... I'll try downgrading ffmpeg now!! |
|
Result... Just got to figure out why it's only launching via sh now 😅 (and on benchmark, multithread score has jumped from 180 to 280!) |
Nice. The stange thing is the emulated version dont require downgrade...
You need to compare version 3.0 x64 with arm, if you comparing prior version it can have slower performance. NET 6.0 optimized some performance |
I'll try comparing to x64 3.0 ver later this eve.
|
I guess i need a new CPU 😂 M1 is a good CPU |
hello everybody, I ran this command :
|
|
@sn4k3 I just got this M1 a couple weeks ago, haven't even installed homebrew yet.
|
|
Again, you dont need dotnet install. All you need is downgrade ffpemg: brew install cmake ffmpeg@4
brew link ffmpeg@4 |
|
@sn4k3 Tiago, I think the confusion maybe is because you're thinking the script line ./UVtools || dotnet UVtools.dll should be succesfully running ./UVtools, and only if it fails does it run 'dotnet UVtools.dll'. Unfortunately though, ./UVtools command doesn't run - the process dies instantly, so then it does try to run 'dotnet UVtools.dll'! Without dotnet being installed via brew in other words, it's not possible to run uvtools. then UVtools works! To put it another way - if you directly try to run 'UVtools.app/Contents/MacOS/UVtools' then it crashes out immediately with a process killed textline, so perhaps it's all a compile issue (may also be why it's necessary to use sh / bash at all, if the main UVtools binary isn't executable?) *I have naturally also checked UVtools (in the Contents/MacOS/ dir) was chmod +x'ed, just to be sure! |
|
@sn4k3 Sorry, I misunderstood. I figured that "You don't need install dotnet since it's included on package...." meant there was a standalone |
|
@sn4k3 After installing/downgrading ffmpeg I'm still getting the same error. Let me know if there's some debugging/tracing I can do to track down the issue. I'll also see if I can get a local build going |
|
@bgyarfas the netframework is all the other files you see in UVtools directory, but as @rfield19 told, it is unable to run without install and run via dotnet, which can mean a missing dependency or missing permition, can you guys just chmod all files within uvtools and give them +x, if it fails then try give full permitions of 777? |
Yep, tried that (set everything to 777 recursively) earlier to see if it would help! (it didn't...) |
|
Maybe it should be compiled on arm?
dotnet restore
dotnet publish -o "publish" -c Release -r osx-arm64 -p:PublishReadyToRun=true --self-contained
Does it works? |
Blimey, compiled it - and running ./UVtools works... Extrapolating from that, I then copied all the files from the publish dir into the UVtools.app/Contents/MacOS dir - and launching it from the app icon then works as well 👍 I then tried (on a fresh download of the release) only copying the UVtools binary into the MacOS dir and that wasn't launchable from the icon, but was still runnable from the sh method. There must therefore be something in addition to the uvtools binary that it needs - and also must be necessary to compile the whole thing on an m1 machine I guess. |
|
Link to new binary |
|
... and from some further tests, the files that have changed in size on the new build compared to the release 3.0.0 are: uvtools bin (of course) |
Well that's not good news to me... I'm gona ask on dotnet git
Those files are not important, but the others are I've updated the release build with yours :) |
Neat - I hope it works ok for others. It was extremely straightforward to compile it with your instructions though, so worst case m1 owners might have to compile their own version until/if you get an m1 machine. I'm not sure about what the other files are that it needs though. |
|
I have asked here: dotnet/runtime#66574
I'm up for offers 😂 |
Auto installer script was changed to make that run-uvtools unnecessary, still testing...
Due previous statement brew and dotnet is not installed and so that script is not updated to reflect the change, which will be on next release.
Try with otool to see what is missing: |
|
otool -l gives: |
|
It not return any missing dependency as it can tell. I don't know but i think there is some compilation bug on macos opencv which allow ffmpeg to link. Both linux and windows builds do not link ffmpeg with the "mini" configuration. It was compiled on another Ventura. What |
|
The command line version I have for ffmpeg was installed by mambaforge (the M1 version of Python Anaconda). When I remove the Mamba paths form my $PATH variable, ffmpeg is not found. (And I can't see any ffmpeg in the uvtools.app) Which path should I be looking in? My Mamba ffmpeg version: |
|
That ffmpeg looks outdated. The macOS by default ship with ffmpeg which on ventura I think should be v5 (Monterey comes with v5). Another solution would be try to compile libcvextern.dylib on your system with removed Mamba paths form $PATH variable to see if it not link with ffmepg which is useless for UVtools and cause this troubles. If you want to try that first see here how |
|
I don't think ffmpeg comes with MacOS, but has to be installed. Updating the Mamba-installed ffmpeg to 5.1.2 has no change in effect when I do the bash-curl install. |
|
It should come in some sort of distribution, maybe libs only. Because prior to cv4.6.0 I always compiled full version which links ffmepg and intel version ran without any required installation. Comparing to linux users had to install ffmepg-dev in order to run UVtools but never on macOS. M1 users had to downgrade ffmepg to v4, indicating that v5 was by default on the system, maybe libs are but bin is not, I don't know. Looking at otool output it gives: Which is telling you have ffmpeg libraries on |
|
I can confirm that I do not have Homebrew, and that there is no /opt/homebrew directory. In fact, every library listed in the otool output is non-existent on my computer. Doing an Diving in: |
|
Ok, so can you try to build the libcvextern.dylib as indicated (Without ffmepg on path) so maybe we can get rid of it? And then bundle that to users.... |
|
Here what dylib should look without ffempg: (My x64 build) |
|
Another command you can try to fetch dependencies (see if output different from otool): |
|
I don't know how to build The output of that |
you just need to follow and run this script
Looks same as otool, but the problem is clear that ffmepg expected on /opt/homebrew but not present on your system. |
|
That script looks like it installs brew around line 56. |
Yes, you can comment or remove that section but you need to manually install that dependencies |
|
Frankensteining together macports and conda installs of various packages, the script eventually gives error messages, but does produce .dylibs: The error message is: The otool output of one of them is: Are any of the .dylib files useful? |
|
Nice, ffmpeg is gone! please try: Zip folder |
|
It works! Here is the zip file. |
|
Thanks, will update dylib with your in next release. |
- **File formats:** - (Add) File extension: .gktwo.ctb to `ChituboxFile` to be able to convert files for UniFormation GKtwo under special CTB format - (Add) UniFormation GKtwo compatibility under CTB format, if exporting JXS rename to CTB before open - (Fix) CTB, CBDDLP, PHOTON, FDG, PHZ: Read and write files larger then 4GB (#608) - **PCB Exposure:** - (Add) Offset X/Y to offset the PCB from it origin - (Add) Allow to toggle between "Show preview image cropped by it bounds" and "Show full preview image (The final result)" - (Improvement) Use rectangle instead of line for center line primitive (#607) - (Fix) Implement rotation to polygon and center line primitives (#607) - (Fix) Macros in a single line was not being parsed (#607) - (Fix) Invert color per file was not affecting primitives - **Network printers:** - (Add) Socket requests with TCP and UDP - (Add) AnyCubic printer preset (However it can't upload a file) - (Add) Scripts in request path to allow a first request to fetch data to the final request: - A script starts with **<\?** and ends with **?>** - First parameter is the first request to get response content from - Second parameter is the regex pattern to match content with - Third parameter is the final request that supports a parameter from regex matching group, eg: **{#1}** is match Group[1] value - **Example:** <\? getfiles > {0}\/(\d+\.[\da-zA-Z]+), > printfile,{#1} ?> - (Change) Allow to print a filename without send it when upload request path is empty - (Fix) Do not show printers with empty requests - (Change) Default layer compression to Lz4 instead of Png - (Improvement) Application is now culture aware but set part of `NumberFormat` to the `InvariantCulture.NumberFormat` - (Improvement) Material cost now show with the current culture currency symbol due previous change - (Improvement) Better submit of bug reports using sections and forms - (Improvement) Linux: AppImage now have a help manual with possible arguments and parameters - (Improvement) macOS: Codesign app on auto-installer and auto-upgrade to bypass arm64 run restriction (#431) - (Improvement) macOS: Rebuilt arm64 libcvextern.dylib to run with less dependencies (#431) - (Improvement) macOS: Try to show missing dependencies from openCV (if any) on the error message - (Fix) UI: layers sorted lexicographically instead of numerically in the issues list view (#611) - (Fix) PrusaSlicer printer parameters: UniFormation GKtwo
|
Need to compile recent OpenCV on M1 again, can anyone compile it? @dmopalmer |
|
Done. Zip attached. (For my reference: and zip the runtimes and attach.) |
|
@dmopalmer I've updated the compilation script to remove a video dependency useless to UVtools. Can you redownload the script, remove compilation folder and re-compile? |
|
Done. |
|
Perfect! Thanks once again! |
|
Hi! recently I found that I also have problem with launching UVtools on M2. I tried to install dotnet runtime, ffmpeg@4. But only thing that helped to me was codesign --force --deep --sign - UVtools.app |
|
@danylkaaa this is an old topic. The dependencies you installed are not required. |
Thanks, this fixed 4.3.2 installation on my ARM mac. |
System
Describe the bug
ARM64 build for osx doesn't run.
Pops a window up with 'The application 'uvtools' can't be opened.'
(non arm64 build of uvtools works fine through rosetta, same as previous versions).
To Reproduce
Run uvtools on m1 mac
See error :)
Screenshots
The text was updated successfully, but these errors were encountered: