@antonio.grazioli All the Autodafe plugins won’t load because of this error:
[0.088 warn src/plugin.cpp:161] Could not load plugin /home/kwilliams/.Rack/plugins-v1/Autodafe: Failed to load library /home/kwilliams/.Rack/plugins-v1/Autodafe/plugin.so: /lib64/libm.so.6: version `GLIBC_2.27’ not found (required by /home/kwilliams/.Rack/plugins-v1/Autodafe/plugin.so)
Same applies to all the Hora music plugins
Hora will be fixed soon I believe, this is the reason: https://community.vcvrack.com/t/rack-v1-development-blog/1149/504
Referencing Andrew’s post about it in the development blog, wouldn’t it seem that the best strategy for compiling plugins for Linux is:
? From the reports I’ve read using wheybags’ glibc_version_header like Andrew mentions has its own set of problems in various cases.
I’m compiling my plugin using Azure Pipelines. Works like a breeze and no need to setup or maintain my own build enviroment.
Other plugins failing with the same error:
Entrian-Free (fixed with version 1.1.0)
Animated Circuits Preview and CZ synths
Autodafe REDs
Possibly other binaries suffer the same problem, I’ve checked only those without a source code repo.
Thanks for the heads-up for Entrian-Free. I’ll fix that ASAP, hopefully later today.
It sounds like the best route is to build on an Ubuntu 16:04 VM, or at least to have one to test on if going down the force_link_glibc_2.23.h route (which would be good because it still uses a more modern compiler).
Does anyone with more experience of this stuff know whether the problems with force_link_glibc_2.23.h that Andrew mentions are always loader errors, or can they be more subtle? If the test of whether force_link_glibc_2.23.h has worked is just “does it load on 16.04?” then that’s easy, but if it actually needs proper testing, for example because something has changed semantically but not in terms of the API/ABI, then that’s much more subtle and would probably make me go down the “build on a 16.04 VM even though you’re using an older compiler” route.
Actually, the free Hora plugins seem to work already on my Linux box.
the free Hora plugins seem to work already on my Linux box
That’s because your Linux install is compatible with the version used to build Hora.
That’s by no means universal. There’s an issue with libm – to which Hora links – expecting a different version of glibc (the basic C support library) than is provided by the libraries already linked & loaded by Rack.
You want to me a favor, send me a copy of the /lib64/libm.so(or /usr/lib64/libm.so) so I can force my Rack script to use that.
But really the issue is that there is a procedure for making Rack plugins with the broadest compatibility, and some plugin authors have not yet embraced that procedure. They’ve promised to do so!
@chaircrusher You wrote:
send me a copy of the /lib64/libm.so(or /usr/lib64/libm.so) so I can force my Rack script to use that.
Good luck. It doesn’t work here, I’ve tried the LD_LIBRARY_PATH dodge with a variety of libm.so.6 binaries, got no joy, but I’d love to learn that it can be done.
For build environments: The azure pipelines approach @stoermelder mentioned which I described in that thread spins up a brand new Ubuntu 16.04 image (and macOS 10.13 and windows 10) and does a clean build and uploads the result to a github release on every push automatically. It takes about an hour or so to set up and is free if your project is an open source project on github. May help?
doesn’t work on all systems (for me failed on Fedora 26)
Paul: Thanks! I’d noted that with interest when it was first discussed, but hadn’t followed up on it because I use a private repo. But having read the MS docs, I see that “If either your GitHub repository or your pipeline is private, we still provide a free tier.”
OK, thanks. I’ll give that option a miss and build on 16.04.
The problems aren’t really affecting open source developers, just people with closed source builds. They obviously don’t want to have public github repos and using them to spin up Azure builds 
No criticism of commercial developers intended. I do have a mild criticism of them that’s more specific: If you’re charging money for your plugin, it’s probably a good idea to make sure your code works on all platforms.
They are probably using the latest LTS (18) or non-LTS (19), whereas 16 is a previous LTS release and thus not really “current.” Using the current releases is convention.
Secondly if your project requires a specific version of libraries (like say, a specific glib) then its also convention to put that assertion in the ./configure script. That’s not in the plugin SDK 
@Richie - Thank you for the new 1.1.0 version of Entrian-Free ! I picked it up from the Library a few minutes ago, loaded it into Rack v1, and tested it with my voice for a while. It works better in some parts of my range, but wow, it works ! Very cool module, thanks again for the update. 
Thanks - I’m glad it’s working for you!
(You’ve probably done this already, but you can tinker with the Lowpass knob to tune it to your vocal range.)
@chaircrusher and @dlphillips, hi guys, if you have a minute to spare, could you try the latest update of the Erica plugin (1.0.2)? I know that it was compiled with the linux include switch referenced above and I’m just curious to see if that fixes things. Thanks!
Hi Marc ! Working nicely here, I just took a test drive for a while with all three modules. Smooth running all the way. Very fine work, up to your usual high standards. Thanks again !