[0.918 info src/plugin.cpp:130 loadPlugin] Loading plugin from /Users/davephillips/src/Rack-2.4-arm64/plugins/NYSTHI
[0.919 warn src/plugin.cpp:196 loadPlugin] Could not load plugin /Users/davephillips/src/Rack-2.4-arm64/plugins/NYSTHI: Failed to load library /Users/davephillips/src/Rack-2.4-arm64/plugins/NYSTHI/plugin.dylib: dlopen(/Users/davephillips/src/Rack-2.4-arm64/plugins/NYSTHI/plugin.dylib, 0x0006): Library not loaded: /tmp/Rack2/libRack.dylib
Referenced from: /Users/davephillips/src/Rack-2.4-arm64/plugins/NYSTHI/plugin.dylib
Reason: tried: '/tmp/Rack2/libRack.dylib' (no such file), '/usr/local/lib/libRack.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/libRack.dylib' (no such file)
Got 'em ! I had to add a link for /usr/local/lib/libRack.dylib, the modules now appear in the browser in my homebuilt Rack 2.4.1 for ARM64. Will test asap. Thank you !
so far, so good, it’s Nysthying like it always did! No crashes or funny stuff yet, although I have only tested 14368 modules of the 1.3455.0988 in the set.
OK, I am nearly through the set (plug in, hook up scope, if applicable pipe signal through, etc. pp. and thus far, as @joopvanderlinden also saw, nothing at all to report, all works as it always had. Doubtful the couple of handful of not yet tested modules will throw up anything…
Just curious, is there any reason you aren’t using the rack-plugin-toolchain? I found that using the Docker version greatly simplifies the plugin build process. One command line builds for all four architectures.
The only fiddly part was the initial step to package the SDK. Once this was done, though, it has been clear sailing.
the only reason is that I’ve built everything starting from the VCVRack main application since the start in 2017 (and I have some old scripts that still work with my XCode )
I think I never considered the rack-plugin-toolchain for laziness…
(I my I feel I have more control on the code… )
Thanks for your answer, it makes perfect sense to me. I’m usually the first to build everything from scratch, but in this case I grew tired of fighting the build tools. So I spent a few hours setting up the toolchain, and afterward I was able to forget about the hassles with the build tools and get back to what for me are the fun parts. But yeah, I cannot fault you for sticking with what has always worked for you (nor for wanting to feel greater control over everything ).
Part of why I asked is because I am still (happily) using an Intel Mac, and you suggested somewhere earlier in this thread that you might not ever again build for the Intel architecture. That’d be a pity… I love so very many of your modules, and I’d hate to lose them because of toolchain issues…
Was gonna say “brew” tripped me up here when recompiling Rack. It decided that Openssl would become version 3 rather than 1.1.1 unless I manually symlinked back to 1.1.1
Laziness, fine. “More control” doesn’t make sense really.
You can develop your plugins with your toolchain of choice, for example Homebrew arm64.
You can use the VCV Rack Plugin Toolchain to build your final binaries for all supported platforms with a known configuration of state-of-the-art compilers and libraries. No more “can’t compile on x86” or “my glibc doens’t work with users” or, in your current case “my macOS changed, and I can’t build”. This is all solved for you with the Docker-based toolchain.
I don’t understand what more control you need. Could you elaborate on that?
A) if I try to use docker in my “personal” m1 mac book pro, with 8 gb, I start to bestemmiate (swear) all the saints in paradise.
B) I like to have a full build in XCODE: I have an xcode project where I can step debug BOTH the main app and the plugins that I compile (generally only mines, because setting up correctly the xcode project is very heavy task)
C) I like to have full build for all the platform because I like to do
debugging
Probably I’ll change the point C:
I’m going to build Windows, Linux and Mc x86_64 using the Rack SDK (without testing anymore in a full build)
I’ll mantain all the debuggin in arm64 (and my xcode coconut)
here an example of my breakpointing a debugging modules in xcode (in this case I’m stopped in “process” of the Core Audio module:
I always ran the toolchain without docker. ran it in ubunto vm inside windows. Never had a problem at all. Although for me it was important to be able to make a build that would be the same as the one in the library. I guess you closed source guys have to do all the builds yourself, so it’s a little different.
And, yeah, I rarely debugged on a “foreign” os, although I sometimes tested in linux because there were/are some good tools there like asan.
I’ve also been unable to build Rack from source on my M1 Mac (both in x86 and arm modes). I have the same errors that OP was getting. I’ve tried suggestions here and in other threads, but I can’t get it to work. I’ve posted about it too, but didn’t get a solution.
In x86 mode, make dep fails just like in this post. The suggestion to remove ="$(DEP_PATH)" from the curl --with-ssl flag does make make dep succeed, but then make will fail with the same error:
ld: Undefined symbols:
_EVP_PKEY_get_id, referenced from:
_ossl_connect_common in libcurl.a[143](libcurl_la-openssl.o)
_cert_stuff in libcurl.a[143](libcurl_la-openssl.o)
I have gone through and the instructions here to have both an x86 and arm version of brew setup.
Building in arm mode also fails for me, with a different error:
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - broken
CMake Error at /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
[...]
error: unknown target CPU 'armv8-a+fp+simd'
It seems @synthi wasn’t able to build for x86 but others have. What am I missing?
I second Squinky’s recommendation. I do all my development from Linux and use the build toolchain to build for Mac and Windows also. So far, it just works, plus I can notice and fix any errors/warnings caused by portability issues before anyone else sees them.