Great thought, but unfortunately having tried that previously it seems to make no difference in this particular situation.
1 Like
Interesting! You’ve inspired me…
So I downloaded the RackFree-2.3.0-lin-x64.zip file, extracted it into a subfolder within my ~/Downloads folder, and ran it (by entering ./Rack from the terminal there). After everything updated this time, it accepted the SurgeXT plugins and they (all) show up - and appear to function properly based on a quick test or two.
This suggests indeed there’s some thing squirrelly about the current AUR-based version of VCVRack that isn’t fully ready for prime time. Mostly it is, but a few (at least 2?) plugin sets won’t update properly - in my case the Fundamental(s) - which is pretty important - and the SurgeXT suite - which is pretty cool and sad to miss.
My next (and hopefully final) step is to see if I can get this VCVRack setup now buried within my ~/Download folder to get moved over into my ~/.Rack folder with the various functioning plugins and report back.
Having uninstalled /.Rack folder in my home directory I’ll need to try this next…
[Aside: “autodaf” now shows up as a plugin I need to update, which I never recall “adding” in the first place, but it won’t load … not a concern, just a curiosity 
]
1 Like
Ha!
Well, the saga continues with a whimper. Ready to put myself out of my misery…
DOWNLOADING DIRECTLY ROM vcvrack.com & LAUNCHING FROM LOCAL DOWNLOAD FOLDER:
Launching the executable in the download folder from terminal, I get all of the plugins installed and functioning (including SurgeXT, Free VCV). But that’s a sloppy solution and requires a terminal/batch file each time to start the program.
INSTALLING FROM THE AUR REPOSITORY:
When I install VCVRack via the AUR the executable goes in the /usr/bin folder @ root (program data goes into a directory in my home folder ~/.Rack2 folder) but then those specific plugins become problematic all over again (e.g., SurgeXT and Free VCV Foundations) and won’t install.
For some reason, copying the executable from the direct download to replace the ‘/usr/bin’ just causes more errors and doesn’t run.
Probably not worth wasting your valuable time (and banging my head against this wall) anymore.
Seems pretty clear that something in the AUR package is broken and I cannot untangle what that might be.
If I ever figure it out I’ll post an update here for future travelers. Meanwhile, thanks to you all for trying! 
3 Likes
I didn’t read everything but if this thread amounts to “I insralled vcv rack from source via aur rather than the binary from rack.com and now surge xt won’t load with some mangled symbol error in the lot@ then
- Don’t use rack from the aur use rack built by the rack environment or
- Don’t use surge from the library build surge yourself from source to be compatible with your build or
- Fix the broken aur build which uses a somehow incompatible glibc with binary builds from rack
A few plugins hit this case but surge is the most popular.
If the issue is something else could someone summarize it again maybe? Lots of messages
Thx
2 Likes
@baconpaul Sorry, yes, this thread got long with the back 'n forth.
I will need to reflect and digest each of your bullet points in the morning and see what I can make of it going forward. Thx!
Is it my imagination, or is arch linux a uniquely problematic platform for VCV?
There are a lot of variables (actual and figurative) to contend with in Arch Linux so it can be easy to miss one and for something to not work. AUR is not Arch Linux and is completely unofficial so unfortunately it’s not uncommon for there to be packaging issues with it.
1 Like
Well done to all the debuggers! The case seems fairly clear now. The Rack build in AUR is no good, so my advice would be to uninstall it and forget about it, and instead just use the Rack directly downloaded from vcvrack.com. You should be able to run that completely normally.
3 Likes
My experience is that software packagers often change build or source flags on open source projects for reasons, resulting in different builds than “official” binaries. Also packaging binaries for the collection of operating environments we mislabel with a singular noun “linux” is hard unless you make some limiting choices. And many packagers don’t run extensive test.
In this case someone wrote a package for rack and didn’t see if it worked, but made it easy to use. I get a support ticket on surge xt rack doesn’t work on arch about every week or two right now.
I think Andrew uses arch as his primary distro so I would not say arch and rack are a bad match. I would instead say arch makes it easy to make unofficial packages.
1 Like
It would be even nicer if someone can remove or fix the broken AUR build. Like I said we are getting a support request across forums with some regularity on this in surge xt. I don’t know how to do this. I run macos ubuntu and windows,
2 Likes
I dont think it is possible to fix this situation. Rack APIs make heavy use of libraries for which the ABI is not the most stable… Recently it was the case of libzstd version mismatch, that was worked around by hiding those symbols and not allowing plugins to use them.
But this kinda thing will keep happening, there is no way around it… plugins typically are meant to have a single entry point which gives a struct or class and expands from there. Rack uses libcurl, libsamplerate, libarchive, libspeexdsp, osdialog… (I mean, it is quite a few libs) which end up being part of what is considered a public API/SDK. These same libraries also exist as system ones on Linux systems, we are bound to have conflicts when the Rack builds vs distro builds mismatch. It happens more often on ArchLinux because as rolling release it updates more often and it is first in line to catch these issues.
The way to go is as you mention, if using a Rack build from AUR then the plugins should also all be from AUR. In my opinion the AUR build should disable online access, it is by chance if binaries from VCV work or not in this case.
2 Likes
whoever made that AUR build should do that, I agree. Or remove the broken build. or build in the rack docker image.
but the situation now - where there is an easy to use subtly broken community distro of rack on arch - is painful.
i guess the free modules also not working in the AUR version will darwinianly fix the problem.
1 Like
I added that comment on what appears to be the GitHub for the packages.
1 Like
Yes, that’s why as Arch users we are targets for mockery and abuse. We seem to suffer the most while operating on the bleeding edge of Linux distros. 
You can thank us for boldly going where no man --help has gone before. 
Meanwhile, I’m still flailing about setting up the direct download to start up more gracefully (like the AUR version installation) to fully enjoy the fruits of SurgeXT, etc. I’ll get there!
Thank you again to all who have helped me get this far … I’ve learned a lot more about the structure of Rack and its plugins through the process
1 Like
I hope my comments didn’t come across as either! Every generation makes a linux distro on the bleeding edge which teaches us a lot about why it doesn’t work, and Arch is definitely the flavor-du-jour of such a strategy.
If you check out that GitHub thread, you see the maintainer points out there is a vcvrack-bin package which may just do what you need.
1 Like
No worries! I thought this was just good-spirited banter 
Will check out the GitHub thread - thx!
UPDATE FOR ANY FELLOW TRAVELERS READING THIS THREAD…
@baconpaul As posted on the git page, thank you again for leading me there.
I was able to makepkg and makepkg --install the bin-git package. SurgeXT and VCVFree plugins now install properly.
FWIW, vcvrack is only 2.2.3 in the bin-git version and is encouraging me to upgrade to 2.3.0 (via the red dot on the Help menu). Having failed miserably before in getting those plugins to install via the RackFree-2.3.0-lin-x64.zip package that upgrading offers as a download, it seems like I’ll just have to wait for someone to produce a bin-git based on the 2.3.0 version. But for now, I’m good to go!
3 Likes
The package for bin looks easy to upgrade
The AUR is setup so you can’t comment on a package unless you install arch first. Pretty developer hostile choice. But since you run arch you could comment on it and ask them to bump the version I guess.
Done.
1 Like