Related JUCE issue: juce-framework/JUCE#979 and forum thread https://forum.juce.com/t/linux-vst3-failure-with-6-1-3-and-4-but-not-2/49448/7

I seem to only run into this on one of my plugins, even when pluginval and the plugin is built on JUCE develop. My plugin template doesn't exhibit the issue. Not sure yet what the difference is....

@sudara, I don't know if it helps, but:

• I used your template as a reference (thanks for that 👍)
• ran into the described issue above
• and got rid of it with this pull request: Update dependency Tracktion/pluginval to v1 JohT/speclet#25

Try if any of these steps might also help you:

• Update to latest version of pluginval
• Move sudo /usr/bin/Xvfb $DISPLAY & to where the linux packages are installed so it gets more time to start
• Install some more linux packages like it is done in the workflow of pluginval. Here is my attempt: JohT/speclet@184ae73

Hey JohT!

Sorry I never closed this issue! It's fixed on the "codesign" branch of Pamplejuce (glad it was helpful for you!) — and you are right, it's fixed in 1.x of pluginval (with the JUCE bump).

In all the excitement with pluginval 1.0, I forgot that I'm actually still seeing this problem on 1.0.1 on my main product. I believe because it opens another DocumentWindow which freaks things out.

It still crashes on the plugin editor opening as described in OP.

Atilla made a recommendation for how to solve in pluginval.

It looks like the issue with direct initialization of Xlib (with JUCE_GUI_BASICS_INCLUDE_XHEADERS=1) that Attila was referencing are namespace conflicts with Time and Status.

/home/sudara/pluginval/Source/PluginTests.cpp:92:31: error: reference to 'Time' is ambiguous
    logVerboseMessage ("\t" + Time::getCurrentTime().toString (true, true) + "\n");
                              ^
/usr/include/X11/X.h:77:23: note: candidate found by name lookup is 'Time'
typedef unsigned long Time;

Tbf we should remove the using namespace juce and make everything fully qualified. It's much better practice and will solve this.

Does qualifying just those indicated uses fix things for now though?

I can confirm removing the extra DocumentWindow makes linux happy.

Attila's second workaround does as well:

std::make_unique<DocumentWindow> ("", Colours::black, DocumentWindow::allButtons);

However, on quit there are some memory leaks, not sure if correlated.

make everything fully qualified.

Yeah, I kind of regret not doing that before the CI stuff, that was the first item I wanted to tackle...

Does qualifying just those indicated uses fix things for now though?

I'll have to look again. There's a fair handful of status/time errors, maybe 20-30. Might be enough to push me into qualifying everything...