[BUG] UVtools 3.0.0 - arm build not functional

[rfield19]

System

• OS: OSX Monterey 12.3
• UVtools version: 3.0.0

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

[rfield19]

For thoroughness, have just tried it on a second M1 machine - same result unfortunately.

[sn4k3]

Yes i know. See related here: https://github.com/sn4k3/UVtools/issues/187 You can run it via sh command, i dont know yet how to put it working via normal way since i have no mac m1 to try. Need community help on here to debug this

To run via sh use a terminal on same UVtools path: sh UVtools.app/Contents/MacOS/UVtools.sh You can create a shortcut for now

[rfield19]

Ah, ok sorry - I thought #187 was just the previous feature request for the arm build. I'm 100% happy to test anything / everything on M1 machines you want to throw at me if that helps at all.

Regardless, congrats on releasing v3 though - you must be exhausted!

[sn4k3]

Ah, ok sorry - I thought 187 was just the previous feature request for the arm build.

It is. But problem was also spoted while i send some test builds there.

I'm 100% happy to test anything / everything on M1 machines you want to throw at me if that helps at all.

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. One thing you can try is give run permission to all files within UVtools.app and also inspect app properties and see permissions

Regardless, congrats on releasing v3 though - you must be exhausted!

I had it on hold for some days by now. But not worth to keep it unreleased because of this situation

[rfield19]

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')) An error occurred while loading required library libhostpolicy.dylib from [/UVtools.app/Contents/MacOS/]

[sn4k3]

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)...

We can keep this thread as #187 was about the arm request and titled as such.

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')) An error occurred while loading required library libhostpolicy.dylib from [/UVtools.app/Contents/MacOS/]

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?

[rfield19]

I thought the same thing - bit of an odd error on an m1 mac.
Perhaps it doesn't think the compiled binary is arm code? I have a handy bit of software called SiliconInfo that tells me if it's arm or x64, but only if the software is running...

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! I think it's mostly complaining that libcvextern isn't present in the contents/macos/ dir?

UVtools.app/Contents/MacOS/UVtools.sh: line 3: 46221 Killed: 9 ./UVtools Unhandled exception. System.TypeInitializationException: The type initializer for 'Emgu.CV.CvInvoke' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'cvextern' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libcvextern, 0x0001): tried: 'libcvextern' (no such file), '/usr/local/lib/libcvextern' (no such file), '/usr/lib/libcvextern' (no such file), 'Downloads/UVtools.app/Contents/MacOS/libcvextern' (no such file) at Emgu.CV.CvInvoke.RedirectError(CvErrorCallback errorHandler, IntPtr userdata, IntPtr prevUserdata) at Emgu.CV.CvInvoke..cctor() --- End of inner exception stack trace --- at Emgu.CV.CvInvoke.Init() at UVtools.WPF.App.OnFrameworkInitializationCompleted() in D:\Tiago\Dropbox\Programming\C#\UVtools\UVtools.WPF\App.axaml.cs:line 198 at System.Threading.Tasks.Task.<>c.b128_0(Object state) at Avalonia.Threading.AvaloniaSynchronizationContext.<>c__DisplayClass5_0.b0() in //src/Avalonia.Base/Threading/AvaloniaSynchronizationContext.cs:line 33 at Avalonia.Threading.JobRunner.Job.Avalonia.Threading.JobRunner.IJob.Run() in //src/Avalonia.Base/Threading/JobRunner.cs:line 181 at Avalonia.Threading.JobRunner.RunJobs(Nullable`1 priority) in //src/Avalonia.Base/Threading/JobRunner.cs:line 37 at Avalonia.Native.PlatformThreadingInterface.SignaledCallback.Signaled(Int32 priority, Int32 priorityContainsMeaningfulValue) in //src/Avalonia.Native/PlatformThreadingInterface.cs:line 39 at Avalonia.Native.Interop.Impl._MicroComIAvnSignaledCallbackVTable.Signaled(Void* this, Int32 priority, Int32 priorityContainsMeaningfulValue) in //src/Avalonia.Native/Interop.Generated.cs:line 4337 --- End of stack trace from previous location --- at Avalonia.Native.PlatformThreadingInterface.RunLoop(CancellationToken cancellationToken) in //src/Avalonia.Native/PlatformThreadingInterface.cs:line 90 at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken) in //src/Avalonia.Base/Threading/Dispatcher.cs:line 65 at Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.Start(String[] args) in //src/Avalonia.Controls/ApplicationLifetimes/ClassicDesktopStyleApplicationLifetime.cs:line 120 at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime[T](T builder, String[] args, ShutdownMode shutdownMode) in //src/Avalonia.Controls/ApplicationLifetimes/ClassicDesktopStyleApplicationLifetime.cs:line 209 at UVtools.WPF.Program.Main(String[] args) in D:\Tiago\Dropbox\Programming\C#\UVtools\UVtools.WPF\Program.cs:line 56 UVtools.app/Contents/MacOS/UVtools.sh: line 3: 46222 Abort trap: 6 dotnet UVtools.dll

[sn4k3]

I thought the same thing - bit of an odd error on an m1 mac. Perhaps it doesn't think the compiled binary is arm code? I have a handy bit of software called SiliconInfo that tells me if it's arm or x64, but only if the software is running...

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).

You dont need install dotnet since it's included on package. But if you do you need the 6.0.3. If sh fails you better to call binary directly: ./UVtools.app/Contents/MacOS/UVtools

About libcvextern thats a common error when you missing any dependency. I suspect ffpmeg need downgrade

brew install cmake ffmpeg@4
brew link ffmpeg@4

Reboot and retry

[rfield19]

I thought the same thing - bit of an odd error on an m1 mac. Perhaps it doesn't think the compiled binary is arm code? I have a handy bit of software called SiliconInfo that tells me if it's arm or x64, but only if the software is running... 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).

You dont need install dotnet since it's included on package. But if you do you need the 6.0.3. If sh fails you better to call binary directly: ./UVtools.app/Contents/MacOS/UVtools

About libcvextern thats a common error when you missing any dependency. I suspect ffpmeg need downgrade

brew install cmake ffmpeg@4
brew link ffmpeg@4

Reboot 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!!

[rfield19]

Result... Downgrading ffmpeg on first machine, and installing ffmpeg on second machine (it didn't have it on there) did the trick...

Just got to figure out why it's only launching via sh now 😅

(and on benchmark, multithread score has jumped from 180 to 280!)

[sn4k3]

Result... Downgrading ffmpeg on first machine, and installing ffmpeg on second machine (it didn't have it on there) did the trick... Just got to figure out why it's only launching via sh now 😅

Nice. The stange thing is the emulated version dont require downgrade...

(and on benchmark, multithread score has jumped from 180 to 280!)

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

[rfield19]

Result... Downgrading ffmpeg on first machine, and installing ffmpeg on second machine (it didn't have it on there) did the trick... Just got to figure out why it's only launching via sh now 😅

Nice. The stange thing is the emulated version dont require downgrade...

(and on benchmark, multithread score has jumped from 180 to 280!)

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.
Thought this wasn't too shabby for a laptop (the second m1 machine) - it's now beating your i9-9900k :)

[sn4k3]

Thought this wasn't too shabby for a laptop (the second m1 machine) - it's now beating your i9-9900k :)

I guess i need a new CPU 😂 But i hand't update that values since NET 5.0, need to re-run with NET 6.0 too

M1 is a good CPU

[aaaldo]

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)...

We can keep this thread as #187 was about the arm request and titled as such.

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')) An error occurred while loading required library libhostpolicy.dylib from [/UVtools.app/Contents/MacOS/]

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?

hello everybody,

I ran this command :

sh /Applications/UVtools.app/Contents/MacOS/UVtools.sh

[bgyarfas]

@sn4k3 dotnet is definitely not being found

~/Downloads 
➜ sh UVtools.app/Contents/MacOS/UVtools.sh 
UVtools.app/Contents/MacOS/UVtools.sh: line 3: 75336 Killed: 9               ./UVtools
UVtools.app/Contents/MacOS/UVtools.sh: line 3: dotnet: command not found

I just got this M1 a couple weeks ago, haven't even installed homebrew yet.

dotnet doesn't appear to be anywhere in the .app either...

~/Downloads 
➜ find UVtools.app -name "*dotnet*"

~/Downloads 
➜ 

[sn4k3]

Again, you dont need dotnet install. instead of sh use bash UVtools.app/Contents/MacOS/UVtools.sh also all that script does is cd to UVtools.app/Contents/MacOS and run ./UVtools It trigger the dotnet else because process have been killed by someother problem

All you need is downgrade ffpemg:

brew install cmake ffmpeg@4
brew link ffmpeg@4

[rfield19]

@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. If you install dotnet via brew though, and then do a

cd UVtools.app/Contents/MacOS/
dotnet UVtools.dll

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!

[bgyarfas]

@sn4k3 Sorry, I misunderstood. I figured that "You don't need install dotnet since it's included on package...." meant there was a standalone dotnet somewhere in the app but more likely it's just build against dotnet. I'm downgrading ffmpeg right now and I'll let you know if that works.

[bgyarfas]

@sn4k3 After installing/downgrading ffmpeg I'm still getting the same error.

~/Downloads 
➜ which ffmpeg  
/opt/homebrew/opt/ffmpeg@4/bin/ffmpeg

~/Downloads 
➜ ffmpeg        
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
  built with Apple clang version 13.0.0 (clang-1300.0.29.3)
  configuration: --prefix='/opt/homebrew/Cellar/ffmpeg@4/4.4.1' --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-avresample --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

~/Downloads 
❯ bash UVtools.app/Contents/MacOS/UVtools.sh 
UVtools.app/Contents/MacOS/UVtools.sh: line 3:  1383 Killed: 9               ./UVtools
UVtools.app/Contents/MacOS/UVtools.sh: line 3: dotnet: command not found

~/Downloads 
❯ otool -L UVtools.app/Contents/MacOS/UVtools   
UVtools.app/Contents/MacOS/UVtools:
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

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

[sn4k3]

@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?

[rfield19]

@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...) Same behaviour unfortunately - the uvtools binary dies immediately on launch.

[sn4k3]

Maybe it should be compiled on arm? Can you try to build it there?

• Clone this repo
• Open a terminal on UVtools.WPF folder
• Then run:

  dotnet restore
  dotnet publish -o "publish" -c Release -r osx-arm64 -p:PublishReadyToRun=true --self-contained

• After you need to copy libcvextern.dylib from my package to that folder
• Run ./UVtools

Does it works?

[rfield19]

dotnet publish $project -o "publish" -c Release -r osx-arm64 -p:PublishReadyToRun=true --self-contained

Blimey, compiled it - and running ./UVtools works... But there's more!

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.

[rfield19]

Link to new binary https://we.tl/t-FnMTe3vo6U

[rfield19]

... 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) UVtools.deps.json UVtools.dll UVtools.pdb UVtools.runtimeconfig.json

[sn4k3]

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.

Well that's not good news to me... I'm gona ask on dotnet git

UVtools.deps.json UVtools.pdb UVtools.runtimeconfig.json

Those files are not important, but the others are

I've updated the release build with yours :) How does it fell compiling such project and making work for mac users? ;)

[rfield19]

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.

Well that's not good news to me... I'm gona ask on dotnet git

UVtools.deps.json UVtools.pdb UVtools.runtimeconfig.json

Those files are not important, but the others are

I've updated the release build with yours :) How does it fell compiling such project and making work for mac users? ;)

Neat - I hope it works ok for others. @bgyarfas, maybe give it a go and see if it works for you also :)

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'll do a proper diff on the directory and see if there's anything else that's changed.

[sn4k3]

I have asked here: https://github.com/dotnet/runtime/discussions/66574 If sign is required even your build will not work for others :/

until/if you get an m1 machine.

I'm up for offers 😂

[rfield19]

You're right about the signing it seems - I've tried that binary on a second m1 machine and it doesn't work. Comes up with 'UVtools is damaged and cannot be opened'. Guess I'll be compiling it on this machine too then!

I genuinely wish I could help with the m1 machine funding thing.
There has to be someone on the facebook group that has loads of money, surely 🤣

[bgyarfas]

Maybe it should be compiled on arm? Can you try to build it there? ... Does it works?

Building from source worked for me as well. I have an Apple developer account so if I can find some time today I'll attempt to code-sign a version to see if @rfield19 can it. I suspect I'll need to build libcvextern as well.

@sn4k3 I haven't looked, but I'm assuming there's tooling somewhere in the repo (or through dotnet) that ultimately creates the .app bundle?

As a completely temporary work around the x64 version works fine on the M1 (Rosetta 2). So for users really wanting 3.0.0 they just use UVtools_osx-x64_v3.0.0.zip for now.

[sn4k3]

I suspect I'll need to build libcvextern as well.

No, it's already compiled, you just need to codesign every binary, there are scripts for that More info on that: https://docs.avaloniaui.net/docs/distribution-publishing/macos

I haven't looked, but I'm assuming there's tooling somewhere in the repo (or through dotnet) that ultimately creates the .app bundle?

I have, but in a windows and powershell env. But creating a .app is very easy, since it's a folder with contents

[Whitespace]

I'm on an M1 Pro running MacOS Monterey 12.2.1 trying to compile 3.1.0.

I think what y'all were proposing is the following. LMK if there's something else to run.

# dependencies
brew install dotnet # 6.0.103
brew install cmake ffmpeg@4

# UVtools repo
git clone https://github.com/sn4k3/UVtools.git
cd UVtools

# build UVtools
cd UVtools.WPF
dotnet restore
dotnet publish -o "publish" -c Release -r osx-arm64 -p:PublishReadyToRun=true --self-contained
cp ../UVtools.Platforms/osx-arm64/libcvextern.dylib .

# run UVtools
./UVtools.sh
  zsh: permission denied: ./UVtools.sh

# max permissions on everything
chmod -R 777 ..
./UVtools.sh
  Could not execute because the specified command or file was not found.
  Possible reasons for this include:
    * You misspelled a built-in dotnet command.
    * You intended to execute a .NET program, but dotnet-UVtools.dll does not exist.
    * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

[rfield19]

@Whitespace just run ./UVtools from the publish dir, rather than the sh script and it should work fine. All the sh script does is cd to a dir and run ./UVtools anyway.

[rfield19]

Incidentally, this is my workflow - as this copies the new files back into the UVtools app, and lets you run it normally from the regular uvtools icon again.

git clone https://github.com/sn4k3/UVtools.git
cd UVtools

# build UVtools
cd UVtools.WPF
dotnet restore
dotnet publish -o "publish" -c Release -r osx-arm64 -p:PublishReadyToRun=true --self-contained

#reassemble app!
cd publish
cp /Applications/UVtools.app/Content/MacOS/libcvextern.dylib .
yes | cp -rf * /Applications/UVtools.app/Contents/MacOS

[sn4k3]

@rfield19 i have created a humble compilation, publish and packing script with all the dependencies and handling in place, produces the same as my release script: https://github.com/sn4k3/UVtools/blob/master/build/CreateRelease.sh

./createRelease.sh -b osx-x64 OR bash createRelease.sh -b osx-x64

also works for linux: ./createRelease.sh -b linux-x64

[rfield19]

Unfortunately not having much luck with that script! It comes up with an invalid grep P parameter error, for the version="$(grep -oP '<Version>\K(\d\.\d\.\d)(?=<\/Version>)' $coreDir/UVtools.Core.csproj)" line

[sn4k3]

Ok maybe mac don't support that grep thing, let me test on my VM

[sn4k3]

It seens mac system grep no longer support -P, lets try perl... Replace that line by this and report back if works:

version="$(perl -nle'print $& while m{<Version>\K(\d\.\d\.\d)(?=<\/Version>)}g' "$coreDir/UVtools.Core.csproj")"

[rfield19]

All went well until step 3 of the script.

  UVtools.WPF -> /Documents/Projects/UVtools/UVtools.WPF/bin/Release/net6.0/osx-arm64/UVtools.dll
  UVtools.WPF -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/
3. Copying dependencies
**xargs: illegal option -- i
usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements] [-S replsize]]
             [-J replstr] [-L number] [-n number [-x]] [-P maxprocs]
             [-s size] [utility [argument ...]]**
4. Cleaning up
5. Setting Permissions
/Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/UVtools.sh
7. Skipping Zip
8. Completed

[sn4k3]

Ok another thing mac dont support: find "$runtimePlatformDir" -type f | grep -i lib | xargs -i cp -fv {} "$publishRuntimeDir/" Let me find an alternative

[rfield19]

Found the xargs one!

-i[replace-str], --replace[=replace-str] This option is a synonym for -Ireplace-str if replace-str is specified. If the replace-str argument is missing, the effect is the same as -I{}. This option is deprecated; use -I instead.

[rfield19]

Another xargs issue... Perhaps it needs the cp -fv command on that line to be in quotes or something?

xargs: illegal option -- f usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements] [-S replsize]] [-J replstr] [-L number] [-n number [-x]] [-P maxprocs] [-s size] [utility [argument ...]]

[sn4k3]

Humm, lets drop that line and replace by: cp -afv "$runtimePlatformDir/." "$publishRuntimeDir/"

[rfield19]

OK, it's running, but it's not executing step 6 - so it's creating the bin file, but not creating the app bundle.

ie if [[ $runtime = osx-* ]]; then...

3. Copying dependencies /Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/. -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/. /Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/./libcvextern.dylib -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/./libcvextern.dylib /Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/./UVtools.entitlements -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/./UVtools.entitlements /Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/./Info.plist -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/./Info.plist
4. Cleaning up
5. Setting Permissions /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/UVtools.sh
6. Skipping Zip
7. Completed

[sn4k3]

Step 6 is zip, not required for you. But if you want to zip you need to pass -z flag createRelease.sh -z osx-arm64 To bundle into a mac app you need to use the -b flag createRelease.sh -b osx-arm64

Edit: Also looks like you have a old fork, pull the new repo because UVtools.entitlements and Info.plist is no longer part of that directory

[rfield19]

Yes, that's what I meant - I did run it as createrelease.sh -b osx-arm64 and it still skipped step 6 (the whole app bundle thing).

edit: I'll redownload latest ver, thanks!

[sn4k3]

if you using git:

git fetch origin
git reset --hard origin/master

Report back if that solved

[rfield19]

Yep, I'm ok with git, just programming I suck at!

updated fork is still skipping step 6 after the -b osx-arm64 argument.

  UVtools.WPF -> /Documents/Projects/UVtools/UVtools.WPF/bin/Release/net6.0/osx-arm64/UVtools.dll
  UVtools.WPF -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/
3. Copying dependencies
/Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/. -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/.
/Documents/Projects/UVtools/UVtools.Platforms/osx-arm64/./libcvextern.dylib -> /Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/./libcvextern.dylib
4. Cleaning up
5. Setting Permissions
/Documents/Projects/UVtools/publish/UVtools_osx-arm64_v3.1.0/UVtools.sh
7. Skipping Zip
8. Completed

[sn4k3]

Maybe another macOS difference...

Instead of if [[ $runtime = osx-* ]]; then try if [[ $runtime == osx-* ]]; then

[rfield19]

It now starts step 6 - getting there!

error on this one next "sed: -I or -i may not be used with stdin"

sed -i "s/#VERSION/$version/g" "$osxApp/Contents/Info.plist"