Linux VST3 - Shared Library does not export the required 'ModuleEntry'

Linux
1

Hello,

I am currently trying to setup JUCE for an Audio Signal Processing course I am taking at Uni. The first project is just to create a handful of standard DAFX such as tremolo. The course instructor suggested either Matlab or JUCE. Matlab is likely the path of least resistance but JUCE looks much more interesting so I thought I’d give it a try.

I am currently running Pop-Os 22.04 LTS on both my desktop and surface tablet/laptop(/thing). I initially tried just grabbing the download off of the JUCE site but Projucer complained about glibc not being up to date enough so I switch to trying to build things from the github page (but first installing the dependencies listed here).

I seem to have JUCE, the demos and projucer built, installed and working. All I did was run the commands on the github:

cd /path/to/JUCE
cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target DemoRunner

Plus make install as well as running cmake and make for Projucer in the /extras.

I have tried creating a basic audio project (following along the create a basic plugin tutorial) via Projucer - making sure VST is check as well as MIDI In/Out.

Projucer sets everything up but when I navigate to the project dir and try to build things with make I am running into some snags:

  1. Whenever I create a project in Projucer no matter what I select for project type if I check the settings after it’s created Projucer has made it a GUI project.
    This is more an oddity than a problem and if I throw in:
    JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP=1 as a preprocessor definition the problem goes away.

  2. Next - VST3 Problems? I seem to be running into a linker error with the VST3 library? I don’t really know what this is trying to tell me beyond something is missing from the shared object file?

bicolor@pop-os:~/JUCE-tut/NewProject/Builds/LinuxMakefile$ make
Compiling Main.cpp
Compiling MainComponent.cpp
Compiling include_juce_audio_basics.cpp
Compiling include_juce_audio_devices.cpp
Compiling include_juce_audio_formats.cpp
Compiling include_juce_audio_processors.cpp
Compiling include_juce_audio_processors_ara.cpp
Compiling include_juce_audio_processors_lv2_libs.cpp
Compiling include_juce_audio_utils.cpp
Compiling include_juce_core.cpp
Compiling include_juce_core_CompilationTime.cpp
Compiling include_juce_data_structures.cpp
Compiling include_juce_events.cpp
Compiling include_juce_graphics.cpp
Compiling include_juce_graphics_Harfbuzz.cpp
Compiling include_juce_gui_basics.cpp
Compiling make_helpers/juce_LinuxSubprocessHelper.cpp
Linking build/juce_linux_subprocess_helper
Compiling make_helpers/juce_SimpleBinaryBuilder.cpp
Linking build/juce_simple_binary_builder
Compiling include_juce_gui_extra.cpp
Compiling juce_LinuxSubprocessHelperBinaryData.cpp
Linking NewProject - Shared Code
Compiling juce_VST3ManifestHelper.cpp
Linking NewProject - VST3 Manifest Helper
Linking NewProject - VST3
The shared library does not export the required 'ModuleEntry' functionmake: *** [Makefile:159: build/NewProject.vst3/Contents/x86_64-linux/NewProject.so] Error 1

Is it possible I missed something important building this? Am I missing something much more obvious than that?
The tutorial does mention that VST3 files come packed with JUCE so I’m assuming I didn’t need to install them manually to my system.

2

Are you’re sure that it’s a plugin (Basic) project and not a GUI app?

1 Like
3

PopOS

IMHO, you’re better off setting up a VM with UbuntuStudio for building Linux-targetting JUCE applications. Sure, you can target PopOS after the fact, but in the meantime you’ll mostly be addressing the extant issues with the Linux target of the JUCE project itself, instead of developing your app further. Once you get the builds working in the ‘native Linux’ environment of JUCE (i.e. the Linux distro which JUCE Linux target developers themselves used - note, they didn’t use UbuntuStudio, but it does work great), switching gears to focus on the distro-specific issues, after the fact of having gotten some app development done, is far more productive. Plus, you’ll have what you need to A/B the different fixes for different Linux targets, and as a bonus, you’ll have a VM workflow which you can then use to do CI/CD.

This is especially important if you are targetting VST with its SDK - reduce your complexity by using the known-good (for the VST SDK and JUCE) Linux distro, and avoid fighting SDK issues as well as JUCE issues.

When you make some progress, re-group around PopOS and spend your productive time addressing issues in the Linux target that might arise as a result of distro differences.

JUCE Application vs. Plugin vs. Plugin Host

This is a common issue - assuming you want to build a JUCE Application, keep in mind that it doesn’t work very well to open the .jucer file and change the type of your project - its really better to re-create the entire project, if you need to change the project type, and then copy the contents of Source/ over, after the fact - if you need to.

Also, great that you’re using CMake - but be careful using Projucer and CMake together. And keep in mind, FRUT exists for a reason …

4

Well one of the issues I encountered is that it seems like Projucer was making a GUI app no matter what I chose.

I tried changing it after the fact but as ibisum observed in their post this doesn’t always work very well.

This is a very reasonable suggestion. I don’t reach for a VM as a starting point as often as I should. I’m always leary of getting hung up on VM specific weirdness but I guess I’m hung up on distro specific weirdness atm.

I’d not actually heard of UbuntuStudio until now but I’ll throw it in a VM and give it a whirl.

I am certainly seeking the path of least resistance (well except for doing the project in matlab I guess). I don’t even need to target VST for the class project (at least I don’t think so) it just so happens to be in the official JUCE tutorials and it seemed prudent to get my feet wet with those first.

Cmake clarification:

I had seen the warnings about mixing cmake and Projucer but I do appreciate your warning as well.

In what I have done so far I have only used cmake to build and install JUCE/Projucer/Demos. For project creation I used Projucer and make only.

I will probably avoid cmake if I can. As much as I’d love to understand it (cmake) better I don’t think JUCE is a the best place to do so.

5

Pop!_OS is an Ubuntu derivative, so, there is no much difference where to play with JUCE.

6

Thats true @KottVV, but there are subtleties in how the bells-n-whistles variants approach things such as libc compatibility versus how the stoic-off-my-lawn distro’s do it, and in this particular case targeting UbuntuStudio is sensible because it has established a distro policy that is conducive to widespread audio-apps/-libs compatibility, as a priority over shiny new stuff. Its just a suggestion to avoid the distro trenches when fighting the battle to build a new JUCE app, especially when just starting out on the adventure …

In any case, the PopOS! experience is of interest to those of us targetting Linux in our JUCE projects - it is after all a popular end-user distro - but one does have to choose ones battles. I have had very few stump issues with building and developing JUCE projects on UbuntuStudio so far …

7

What is wrong between glibc compatibility between Ubuntu derivatives?
I build JUCE apps/plugins for openSUSE, Fedora, Debian/Ubuntu and Mageia, there is no any “subtleties” except the package names, like libjack-devel vs libjack-dev vs jack-audio-connection-kit-devel.

8

The projucer indeed appears broken on PopOS 24.04. No idea what is going on there.

But selecting “plugin” as the project default generated a correct Makefile and it worked as expected. I couldn’t edit the project name though, and the file explorer appears broken.

Sticking to cmake is probably the best option. It’s just a bit of boilerplate you write once (for simple projects).

9

So despite getting a basic project build-able with cmake I thought I would be pragmatic and stick to matlab for the first course project.

This proved to be a mistake.

  1. Matlab’s own audioTestBench GUI for testing plugin code introduces latency or some other issue that has me spending a week thinking I was implementing the effect incorrectly. Turns out once I bypassed audioTestBench and fed in audio files directly to the effect in code there was no issue.
  2. Bonus - turns out matlab can’t generate a vst plugin on linux and their audioTestBench and instead wants to generate a JUCE project instead.

So I’m back in my VM with code that matlab code-gen’d to cpp and a .projucer project file. Matlab has supplied me with 16 .cpp/.h files so ideally if I can just get Projucer to generate a Makefile that would be lovely as I don’t relish the idea of me trying to put together a CMakeLists.txt for 16 code generate files (maybe I’m overestimating how difficult this could be).

As mentioned earlier in this thread while Projucer launches it is a bit janky (GUI doesn’t refresh unless I minimize/maximize) but it does open the projucer project that matlab gave me buuut the Linux makefile penguin icon is greyed out.

I presume I need to be able to click that icon to have projucer generate me a makefile?

Just poking around modules being highlighted in red for linux makefile is probably bad.

image
image1193×804 132 KB

So I swapped out the global option for an explicit path to /usr/local/include/JUCE-8.0.2/modules/ for all the juce modules and still no penguin.

I’m not sure what else to look for. I haven’t found anything else highlighted in red.

10

This bug in 8.0.2 was fixed in 8.0.3. Please try updating and let us know if the problem persists.

This is because there’s not a ‘standard’ IDE, like Xcode or Visual Studio, for working with Makefile-based projects on Linux. You should still be able to select the “Save Project” entry in the “File” menu to generate all the project files. Then, in a terminal, you can run make from the Builds/LinuxMakefile subdirectory of your project directory.

11

Ah! Okay, I’ll give updating a whirl. Thank you for the response : )

Interesting, I saw something to this effect on a forum post about it not being a ‘standard’ IDE but thought the design language implied that you still clicked the “IDE icon” to generate the Makefile.

Since I made my last post I have discovered that the 8.0.2’s Projucer also silently fails to save the project via the “File” menu which would be why I never discovered that this triggers the Makefile generation.

I will update after I update.

12

Well Projucer works now, it was able to make me a Makefile, and I was able to build me a .vst3 directory.

Unfortunately I can’t get the plugin that is generated to work. I don’t think this is a JUCE problem or at least I have no way of knowing. There are too many moving parts.

I tried loading it in:

  1. Audacity (which only comes an an appImage on Linux) just loads a blank GUI when I open the plugin.

  2. Ardour loads the GUI with the correct parameters but the moment I try to pump an effect through it Ardour crashes D:

I have no idea if this is the plugins fault or ardour or the virtual machine it’s all running in.

I did Ardour via gdb out of curiosity. Something bad is happening with memory allocation. I’m willing to bet someone is getting janked up doing code gen from matlab to cpp.

UCE v8.0.3                                                                                                                                                                                                                                
[New Thread 0x7fffb6c006c0 (LWP 3482)]
[New Thread 0x7fffb62006c0 (LWP 3483)]
[Detaching after fork from child process 3484]
[Thread 0x7fffb6c006c0 (LWP 3482) exited]
[Thread 0x7fffdba006c0 (LWP 3472) exited]

Thread 1 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
Download failed: Invalid argument.  Continuing without source file ./malloc/./malloc/malloc.c.
malloc_consolidate (av=av@entry=0x7ffff5403ac0 <main_arena>) at ./malloc/malloc.c:4849
warning: 4849   ./malloc/malloc.c: No such file or directory
(gdb) thread apply all bt
...
Thread 1 (Thread 0x7ffff0541d80 (LWP 3385) "ArdourGUI"):
#0  malloc_consolidate (av=av@entry=0x7ffff5403ac0 <main_arena>) at ./malloc/malloc.c:4849
#1  0x00007ffff52aba80 in _int_malloc (av=av@entry=0x7ffff5403ac0 <main_arena>, bytes=bytes@entry=37248) at ./malloc/malloc.c:4041
#2  0x00007ffff52ad6e4 in __GI___libc_malloc (bytes=37248) at ./malloc/malloc.c:3336
--Type <RET> for more, q to quit, c to continue without paging--
#3  0x00007fffb75080fc in juce::HeapBlock<juce::PathStrokeHelpers::LineSection, false>::reallocWrapper(void*, unsigned long)::{lambda()#1}::operator()() const (__closure=0x7fffffffc680) at /home/kine/JUCE/modules/juce_core/memory/juce_HeapBlock.h:364
#4  0x00007fffb75103d0 in juce::HeapBlock<juce::PathStrokeHelpers::LineSection, false>::wrapper<juce::HeapBlock<juce::PathStrokeHelpers::LineSection, false>::reallocWrapper(void*, unsigned long)::{lambda()#1}>(unsigned long, juce::HeapBlock<juce::PathStrokeHelpers::LineSection, false>::reallocWrapper(void*, unsigned long)::{lambda()#1}&&) (size=37248, f=...) at /home/kine/JUCE/modules/juce_core/memory/juce_HeapBlock.h:341
#5  0x00007fffb7508144 in juce::HeapBlock<juce::PathStrokeHelpers::LineSection, false>::reallocWrapper (ptr=0x0, newSize=37248) at /home/kine/JUCE/modules/juce_core/memory/juce_HeapBlock.h:364
13

It’s difficult to say from the information you’ve provided. It looks like the crash in Ardour originates from JUCE’s graphics context, but there’s no way to say why. Supplying the rest of the stack trace might help, but it’ll probably be difficult to draw any conclusions without seeing the code and debugging the program state at the point of the crash.

Have you modified the UI of the plugin in any way? Given that the crash seems to originate in the UI, it might be interesting to try simplifying the UI as much as possible (e.g. commenting everything out) to see whether this allows the plugin to work. You could then add parts back in gradually to find out where the problem originates.

I’d also recommend testing with REAPER. This host normally does a very good job of hosting plugins (I’m less familiar with Audacity and Ardour). If you still see crashes in REAPER, this would indicate that the problem is most likely in the plugin, rather than in the host.

14

Wanted to update that I’ve now observed a very similar crash in a different situation. This is due to a bug in JUCE, and there’s a fix on the way. I’ll update this thread once the fix is published.

In the meantime, I believe that the problem should not be present when building in Release mode, so you could try that to see whether the resulting plugin works:

CONFIG=Release make
15

Oh, this is a surprise. Apologies I could have provided a more detailed backtrack but immediately got caught up in the wash of other school deadlines.

I’ll give release a try. Thank you for investigating!

16

Well in good news. Release does not crash when fed audio. In bad news I don’t get any audio out of the plugin but I think that’s solidly into the territory of I don’t know what the generate code is doing. I’m better off refactoring directly into a JUCE project.

Thank you for the assistance!

17

I believe that the following commit on the develop branch should fix the issue:

Please try updating your copy of JUCE and check whether the problem persists. If you’re still seeing crashes, then maybe the root cause is elsewhere after all.

18

Apologies for the delay. So I switched to develop branch, ran git fetch, followed by git pull. Opened up projucer and switched all of the modules away from the global libraries and pointed them at the modules for in the cloned JUCE repo.

However, now make fails with:

kine@l:~/delayEffectsPlugin/Builds/LinuxMakefile$ CONFIG=Debug make
make: *** No rule to make target '/home/kine/JUCE/modules/juce_core/javascript/juce_JSON.h', needed by 'build/intermediate/Debug/include_juce_audio_plugin_client_VST3_dd633589.o'.  Stop.

I do also see :

JUCE Assertion failure in jucer_Project.cpp:2808

A whole bunch in the terminal.

Just in case I messed something up I re-cloned the repo and tried again. Same result. Oddly exactly the same error even though on the second attempt I repointed the modules to the second copy of the JUCE repo at a different path and saved the project.

So I deleted the LinuxMakefile directory (should have started here) and then re-saved the project.

This time it would build and no crashing in Reaper or Ardour.
Alas, of course still no plugin effect but I was expecting that.

Thank you for figuring this out :slight_smile:

19

Just some pointers - I regularly do builds of my plugins on Linux, and have managed to side-step the issues you’ve encountered, mostly because of differing methodology, I guess.

Make sure you run git submodule update --init --recursive after a fresh JUCE clone.

I have had most success with JUCE on Linux using CLion as my IDE, meaning CMake-based projects, and REAPER for testing. (Note, we also have Studio One running on Linux now, in-house, for testing.) I very rarely ever use Projucer these days, except for maybe the occasional testcase/workbench project that I just want to rapidly set up - otherwise I can just use my other plugins CMake files as a template, which works quite well.

And one last tip: unless you really need 8.x features, its best to get your project working on Linux with JUCE 7.0.13, which has ‘settled’ a bit better than the current mad pace of develop allows. I’ve managed to avoid a lot of headaches by holding back on participating in the mad update frenzy that is happening on the develop branch of 8.0.x these days … there is a lot of action there.