Building my VST3 with Linux and JUCE6 - couple of tiny things

So the good news: I took my plugin ported to JUCE6, and I can now run a VST3 of it in Ubuntu 20.04 Reaper 6.09. Thank you. that is amazing

There are two things that, at head of the juce6 branch, aren’t correct for my setup though and I had to fix.

First my binary data required -fPIC so i added

  message( "FPIC Baby" )
  target_compile_options( tuning-workbench-synth-binary 

to my cmakefile to get it to build.

Secondly, the vst3 which resulted (in build/artefacts/tuningworkbenchsynth.vst3) had a misnamed file. Inside the directory structure was “Contents/x86_64-linux/tuningworkbenchsynth.vst3” which means REAPER won’t scan. If I rename that to the correct name “Content/x86_64-linux/” then it works.

I’ll dig into the cmake stuff a bit later on to see where that name is set if noone else tells me what I’m doing wrong :slight_smile:

All my code is GPL3 and on the juce6 branch

Thanks for any thoughts. I can’t beleive I got this to run as a VST3 in Reaper. Amazing! Thank you again.

Thanks for trying out JUCE 6! A more ‘modern cmake’ way of setting the PIC flag which is portable between compilers would be:

set_target_properties(tuning-workbench-synth-binary PROPERTIES

I’ll take a look at the linux/vst3 issue, and should have a public fix in a couple of days.

Awesome thanks!

Is it something about Ubuntu or my project specially, or do you think that should be set for all the binary targets?

Juce 6 is great. Thanks for making it awesome. I still can’t quite make the surge vst3 work in every Linux host and I did a lot more work there than the 20 minutes of cmake for tws I did here!

It’s specific to plugins on Linux, I think. The CMake functions in JUCE should automatically enable position independent code (PIC) when building plugin targets - however, the functions don’t enable PIC on other target types (such as binary code targets) because these targets may be linked to executables which do not (necessarily) require PIC.

Really glad to hear you’re enjoying using JUCE 6!


The vst3 vs so bug looks like conflating the dll extension with the plugin extension. Makes sense on windows where you rename a dll to .vst3 if you don’t use the bundle thing.

For linux I did this fix

diff --git a/extras/Build/CMake/JUCEUtils.cmake b/extras/Build/CMake/JUCEUtils.cmake
index f7de9ca15..b3d3e75d4 100644
--- a/extras/Build/CMake/JUCEUtils.cmake
+++ b/extras/Build/CMake/JUCEUtils.cmake
@@ -1138,12 +1138,21 @@ function(_juce_set_plugin_target_properties shared_code_target kind)
         set_target_properties(${target_name} PROPERTIES
             BUNDLE_EXTENSION vst3
             PREFIX ""
-            SUFFIX .vst3
             BUNDLE TRUE
+        if(CMAKE_SYSTEM_NAME STREQUAL "Linux" )
+            set_target_properties(${target_name} PROPERTIES
+                SUFFIX .so
+            )
+        else()
+            set_target_properties(${target_name} PROPERTIES
+                SUFFIX .vst3
+            )
+        endif()

and I got a working vst3. but I do wonder if that suffix is also wrong for mac and other bundled platforms. Hope that helps!


Oh on mac it doesn’t matter since you don’t give a prefix to the dll and you put the right thing in Info.plist. So this really is just linux seemingly carrying over the dll name from unbundled windows. (Also my plugin builds fine on mac on my juce6 branch :slight_smile: )

Is it possible to compile VST in Linux for Windows with Juce 6?

No, JUCE does not officially support cross compilation. To build a plugin for Windows, you’ll need to use a Windows build machine.

Is that mean, I can’t compile on Windows for Mac?

Yes. To build for Mac, you need a Mac build machine. To build for Windows, you need a Windows build machine.