Hmm, works fine on 13.5.1 (Ventura) . Might be your local build that causes this. Can you try with the official 2.4.1 release?
compiled against the v2.4.1 VCVRack tag (FYI)
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.
3 Likes
I’d like to add another link that helped me in solving the problem
I had a very fuxxed up brew installation mixed between arm64 and 86_64 …
2 Likes
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…
2 Likes
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… )
I was scared seeing/hearing the power of arm64 
seas
1 Like
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…
I created a NEW rosetta environment to support people still using Intel Mac
here the test version
2 Likes
Thank you!
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
1 Like
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?
3 Likes
More control :
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.
1 Like
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 depfails just like in this post. The suggestion to remove="$(DEP_PATH)"from the curl--with-sslflag does makemake depsucceed, but thenmakewill 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?
This may not help at all, but I build using the rack toolchain in Linux. It will make builds for mac intel / mac arm / windows / linux intel.
1 Like
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.
For sure you need to build in Linux, if only to make sure you didn’t introduce a case sensitive filename issue (which I do all the time). But it’s a good point that you can see all those “other platform” warnings going by! Now I just need to fix some of them