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
if( UNIX AND NOT APPLE )
message( "FPIC Baby" )
target_compile_options( tuning-workbench-synth-binary
PRIVATE
-fPIC
)
endif()
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/tuningworkbenchsynth.so” 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
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.
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.
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 )