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.
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.
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.
$ 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)
Thread model: posix
[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
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
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.
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