How to build cross-platform plugins

A quick one, perhaps rooted in a misunderstanding of the Projucer. If I’m developing on an M-series Mac on XCode, is it possible to build the binaries for other architectures? Is CMake the only option? Thanks!

Projucer will allow you to save XCode, Visual Studio and Linux make projects.

A popular approach is to forgo Projucer and directly use cmake. Takes some effort to configure but will give you unbounded flexibility.

FRUT on GitHub is a useful tool for generating cmake files from Projucer files. Works great with clion.

3 Likes

Got it, thank you! As a follow-up question: Will the Projucer XCode project let me build for Intel Macs or only M-series? If so, how do I configure that?

You don’t need to anything special in Projucer to build for Intel or M-series Macs. It’s a setting in Xcode. At the top of the Xcode window it says “My Mac”. Click on that and select “Any Mac”. Now when you build, it makes a version that runs on both Intel and M-series.

(For a version that works on Windows you will have to open the project in Visual Studio on Windows. There’s no way to cross-compile between Windows and Mac.)

2 Likes

Awesome! Thank you!

Following up, if I’m linking an external library it seems that it can’t actually build it properly for x86. Is there some way of pulling an x86 version of a library on M3 only for building purposes?

Not sure exactly what you’re doing but if the external library has already been compiled, it should have both x86 and ARM versions inside the library or it’s not going to work.

1 Like

I installed the (pre-compiled?) library via brew. My knowledge of this part of the development process isn’t the greatest though. Looking through my lib directory I see the files are installed as .dylib files, which I assume are architecture specific? Thanks for all the help so far!

libcrypto.3.dylib
libcrypto.a
libcrypto.dylib
libcryptopp.a
libcryptopp.dylib

From Terminal, in the dir where these libraries are installed, use file libcrypto.dylib to see which processors it supports.

Maybe Homebrew only installed the version for your computer. This certainly seems to be the case on my machine (it only has an arm64 slice in it).

You may need to install the -dev version of this library in order to link it with your own program.

1 Like

Yep, file command shows it’s just ARM64. I’ll try using the -dev version, then. Thank you!

I ended up having to build the library from source, and while I got it to build, and even got it to link at compile-time, now the juce_vst3_manifest is throwing up issues during the plugin copy/signing phase. It seems like it’s expecting the build to copy over the dynamic library into the build folder? This wasn’t triggering before which is odd. Could I just add a cp libcryptopp.dylib /PathToMyPlugin/Builds... as a post-build command?

dyld[2742]: Library not loaded: libcryptopp.dylib
  Referenced from: <99E9CACF-13D6-3FB2-8A5C-7314A8FA7A34> /PathToMyPlugin/Builds/MacOSX/build/Debug/juce_vst3_helper
  Reason: tried: 'libcryptopp.dylib' (no such file),'/PathToMyPlugin/Builds/MacOSX/libcryptopp.dylib' (no such file)

Yeah, you want to put the copy step in the post-build event.

You’re doing the right thing building it yourself, as you can control things like the OSX_DEPLOYMENT_TARGET and the archtectures which you can get into trouble with using a pre-built library.

However I’d suggest if you can building a static library and just linking it into the product, avoiding the copy step completely. I can’t remember how much of a pain in the arse this is with libcrypto :slight_smile:

1 Like

Thanks!

I eventually got it to build, but it seems that the error messages I had gotten while compiling the universal binary meant the arm64 version of the library worked, while the x86 version did not.

I’ll try to build it static, but I took a look at crypto++'s own documentation on universal binaries and it mentioned some particular issues with doing arm64 builds, tho I don’t know how pertinent that is, as the last edit on that page was 3 years ago.

Worst case could I build both versions of the library separately?

Yeah you can build them separately and if necessary stick them together with lipo?

1 Like