Vult Free v2

Announcements
34

Thanks for the report. I think I know what’s the issue. I started building the modules with GitHub - VCVRack/rack-plugin-toolchain

It seems like the windows compiler there has a bug that I’m hitting. I have code like this:

void initializeBuffer(Context &ctx) {
   for (int i = 0; i < 1000; i++) {
       ctx.buffer[i] = 0.0f;
   }
}

Using the mingw gcc compiler turns this code into an instant crash. The code works fine on Mac and Linux.

I’m trying to find a workaround this issue. Because it affects all the modules that have a large buffer.

35

I have had problems a LOT where my local build runs fine in windows, but the one from the rack toolchain crashes. I have never found out the source of the problem, but I used to work around it by building in a Linux VM with the “real” rack toolchain, then keep changing the code until it didn’t crash any more. In my case it was always c++ library functions like std::stringstream, or the boilerplate that lets you catch an exception. Never could prove it wasn’t just something in my code, although I did run it in linux under address sanitezer and found no issues.

36

I’m having the issue on Mac.

37

Ubuntu 18.04 VCV Rack Free v2.beta.1

[0.199 warn src/plugin.cpp:170 loadPlugin] Could not load plugin /home/dlphilp/src/Rack2/plugins/VultModulesFree: Failed to load library /home/dlphilp/src/Rack2/plugins/VultModulesFree/plugin.so: /home/dlphilp/src/Rack2/plugins/VultModulesFree/plugin.so: undefined symbol: _ZSt28__throw_bad_array_new_lengthv

38

me too.

39

Notice “not built yet” and “alpha status”.

40

We have updated the rack-plugin-toolchain v2 to the latest cross-compilers available for all platforms.

One artifact of this are changes in gcc 11 where there are issues at runtime when loading plugins into a Rack version that is not compiled with (at least) gcc 11. This results in the error that @dlphillips posted above (undefined symbol: _ZSt28__throw_bad_array_new_lengthv).

If you load the the Vult modules @modlfo provided in the official Rack beta, they will load fine, because it was compiled with gcc 11.

Other issues @Squinky mentioned are purely anecdotal at this point since we don’t have enough data with the new compilers to know if there are still differences between the native (mingw-based) Windows compilers and the (mingw-based) cross-compilers used for the rack-plugin-toolchain.

I have been compiling all available open source plugins for v2 with the rack-plugin-toolchain and tested runtime with the official Rack releases on all platforms. So far I have not encountered any issues that could be traced back to the rack-plugin-toolchain.

The above mentioned gcc 11-related issue is somewhat unfortunate for people compiling from source and we keep monitoring availability of gcc 11 releases that might resolve this. Until then, you can compile your local Rack version with a more recent compiler to resolve this issue.

1 Like
41

Can you please elaborate why you think that this is a problem with the compiler? Does this also happen with a native Windows build (which, btw, also uses the mingw gcc compiler)?

42

@cschol Thanks for the update. I’m running Ubuntu 18.04, apparently I need to upgrade to 20.04 ?

43

Ubuntu 20.04 uses gcc 9.3.0. I build gcc 11 from source.

44

I’m using the Rack Pro developer’s beta, compiled by VCV, and the Vult files provided by @modlfo (including the commercial ones)

I get the same problem with Basal VCO discussed above. (I’m on Mac)

2 Likes
45

Interesting. I wonder if that goes the other way as well (Rack ↔ Plugin) and accounts for my problems yesterday. On my Mac (10.12 Sierra) I downloaded the Rack v2.beta-1 which installs and runs fine. I also downloaded the corresponding beta-1 SDK. I then downloaded the Bogaudio source from Github at the V2 branch. I built the plugin just fine, but when Rack was loading it, it kept throwing these “undefined symbol” errors.

Local compiler:

$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
46

Okay, thanks. So the situation now requires a home-built version of GCC, correct ? As you said, unfortunate, but I can do it. What options are you using to build gcc-11 ?

[Edit] If I understand correctly I will have to build v2 with gcc-11 if I want to run any proprietary plugins on a local build. Is that right ?

47

Can you please send me the exact “undefined symbol” errors? There is a known issue with the SDK that will be fixed in the next Beta release. I need to check that. Thanks.

48

The rack-plugin-toolchain uses crosstool-ng.. I recommend using that. Look at the Makefile.

Yes.

49 
[0.859 info src/plugin.cpp:117 loadPlugin] Loading plugin from /Users/lab/Documents/Rack2/plugins/Bogaudio
[0.867 warn src/plugin.cpp:170 loadPlugin] Could not load plugin /Users/lab/Documents/Rack2/plugins/Bogaudio: Failed to load library /Users/lab/Documents/Rack2/plugins/Bogaudio/plugin.dylib: dlopen(/Users/lab/Documents/Rack2/plugins/Bogaudio/plugin.dylib, 6): Symbol not found: __ZN8bogaudio12FollowerBase17efGainMaxDecibelsE
  Referenced from: /Users/lab/Documents/Rack2/plugins/Bogaudio/plugin.dylib
  Expected in: flat namespace
 in /Users/lab/Documents/Rack2/plugins/Bogaudio/plugin.dylib

So, not “undefined symbol” but “Symbol not found”. I then started hacking out modules to see if it was just a minor problem with a couple of them, but each time got new/different “symbol not found” and gave up. I did eventually get it to make a plugin that loads though, with just one module, the analyzer.

[0.815 info src/plugin.cpp:117 loadPlugin] Loading plugin from /Users/lab/Documents/Rack2/plugins/Bogaudio
[0.823 info src/plugin.cpp:175 loadPlugin] Loaded Bogaudio v2.0.39
50

That’s a symbol that is missing from Bogaudio. The other errors are symbols missing either from gcc or the Rack SDK.

This has to be something else. Are you sure you did a clean build?

Christoph

51

This happens even when compiling directly on a windows machine. I hit this problem a long time ago and switched to clang which does not have that problem.

I have tried a few things, like compiling with -O0 and changing the code to use memset instead. Butt nothing seems to workaround the problem. I tried to not initialize the memory and fix any issues when reading the buffer by clamping the read values but that solution is not good enough since it can produce burst of noise when opening a patch.

In summary:

  • gcc on linux works
  • clang on mac works
  • gcc on windows (including cross compilation from linux) crashes
  • clang on windows (including cross compilation from linux) works
1 Like
52

Yup. But it’s Ok, maybe Bogaudio is not up to speed with latest SDK.

53

I have updated the binaries in

This should fix the issues in Basal, Trummor 2 and poossibly others.

I have to recompile them using my old build system.

5 Likes