Ok thank you for the info,
Will reinstall a virtual machine and hope it will be OK.
Will take more than 50 minutes for me since I do’nt know well linux but much faster than the tool chain 
The toolchain is designed to create a cross-compilation environment on Linux.
The Docker solution is convenience for myself.
The Docker environment - in theory cross-platform - has issues on macOS and specifically Windows, which I attribute to Docker performance on those platforms.
I have seen issues with parallelized builds that work fine on Linux and fail consistently on macOS. Therefore, I have to build the toolchain on macOS with JOBS=1, preventing parallelized builds. This takes a long time.
I have never been able to successfully build the toolchain on Windows in the Docker environment.
For building Linux builds, I recommend you use a Virtual Machine with Ubuntu 20.04 and use the toolchain build without Docker by running
make toolchain-lin
This will build the correct compiler version incl. the correct libc for the Linux build.
The binaries for the toolchain will be located in local directory, which the build process creates inside of the rack-plugin-toolchain source tree.
Set the following environment variables:
export PATH:=<location of your local dir>/x86_64-ubuntu16.04-linux-gnu/bin:$(PATH)
export CC := x86_64-ubuntu16.04-linux-gnu-gcc
export CXX := x86_64-ubuntu16.04-linux-gnu-g++
export STRIP := x86_64-ubuntu16.04-linux-gnu-strip
And you can build the plugins from the plugin source tree with:
RACK_DIR=<location of Rack SDK> make
1 Like
If you need to test or build something quickly then you can boot into a linux distro on a USB stick.
Trying fedora: whatever I tried to install I got a “comand not found” error. This was the final straw, I have smashed my computer and there is good chances it is broken.
Not proud of it of course, I am somebody pretty calm but after those two days passed on toolchain and automoate builds for barely nothing I’ve completelty lost the control for a few seconds…
To be continued…
Ouch - I feel for you.
Maybe go and do something different for a bit (walk/run/ride/swim/ski/wine) and then come back to it with a fresh mindset. Good luck 
In a post, 13h ago, there was something about what version of Linux use.
Please make it clear to the developers - if it isn’t allready - what versions they are supposed to use - or the volunteer un-paid supporters in various communities have needless work to do with figuring out what the users did wrong.
1 Like
Yes, but the plugins aren’t OK in the library and users are waiting. My laptop seems to still work (miracle because the schock was pretty hard) I continue, probably not good for my mental health but I’m at the point where nothing will calm me down…But thank you for your support
3 Likes
Yeah I saw, this was posted a few seconds after I had passed my day compiling it all using this technique. This will probabaly never be OK since github actions seems to not support either version of Ubuntu that are OK for VCV plugins compiling.
I just desinstalled ubuntu for fedora… Ok will give a try like you suggest
Thank you
You are confusing building the plugins with building the toolchain. Christoph recommends building the toolchains in a Ubuntu 20.04 VM, but the plugins themselves are built using a 16.04 toolchain.
1 Like
OK, thank you - I should have noticed that.
You need to understand what the toolchain’s purpose is and how it accomplishes its task.
The Host OS that the toolchain is built on, does not matter for all intents and purposes. Ubuntu, Fedora, Arch, all of them work. The Makefile is pretty agnostic to distribution (with the exception of the dep-ubuntu target, which is made for Ubuntu). I use Ubuntu 20.04 in the Docker image.
The toolchain builds the compiler and all relevant tools and libraries, like libc, to build the plugins. If invoked correctly, the toolchain does not use the Host OS compiler and tools and only a minimum of host-level libraries.
The main issue is that this is not a turn-key solution for everyone. You need to know your way around in a GNU/Linux environment and be able to troubleshoot. We tried to make this is as simple as we can, but given the complexity of the task, is cannot be made much simpler. There is a certain level of knowledge that is required to use it. You need at minimum be able to read and use a Makefile and potentially know your way around Dockerfiles and Docker. If you dig deeper you will find osxcross and crosstool-ng as platforms providing toolchain build capabilities.
The intent of the toolchain is to create a reproducible environment for a) integration (what I do) and b) the official Rack build system. Both steps use the same toolchain so we ensure that plugins that pass integration do not fail during the official build step.
The toolchain represents the official way to build plugins. It is open-source so developers can take a look and see how it works and adjust it to their needs. If open-source developers would like to stay close to that environment, they should use the toolchain, but they don’t HAVE TO. The risk is that there will be issues found during integration.
Ideally, we would be able to provide the toolchain as a turnkey solution that developers of all platforms and skill levels can use. That is not feasible at this point for various reasons, for example licensing of the macOS SDK or the overall complexities of the build process, which require GNU/Linux knowledge as mentioned above.
4 Likes
I can’t imagine having to wait 11 hours for single threaded build of the toolchains. Building the toolchains in a Docker on Arch takes me about 25 minutes with JOBS=20. It builds consistently successful with a minor change to the Makefile. While building the Windows toolchain, parallelized crosstool seems to need more than 1024 open file handles and the build fails. Adding --ulimit nofile=4096 to the “docker-build” section fixes that. Please note that I’m using podman, not docker.
2 Likes
Yeah, I am only building the toolchain on my macOS laptop if I absolutely have to. My main build machine is a Linux box and it takes maybe an hour to rebuild on that.
How are you building the image to use with podman? I read that it does not come with a builder toolset itself, like docker build.
Podman is 95% syntactically equivalent to docker. it has podman build that does the same as docker build. Moreover, you can symlink/script/alias podman to docker and most projects will build fine.
The toolchains, for example, build fine on my system without modifying the Makefile’s docker-build and DOCKER_RUN definitions. Arch actually has a meta-package that does the docker<->podman magic for you, including re-writing all podman man files to man docker-xxxx.
Podman, in addition to having a podman build, has an extended build system called buildah that allows a much finer grained control on building. I use buildah ,for example, to update the toolchain image with new SDKs without re-building the whole thing (yes, 25 minutes is too much for me 
). I start an interactive toolchain container instance, make a change to the version inside the Makefile, delete the SDKs and run the toolchain-all target to get only the updated SDKs. I then stop the container, and with a single buildah commend I commit and squash the container into a new toolchain docker image. Takes me just about 5 minutes. I also prefer podman as its able run rootless containers and does not use a privileged central daemon as docker does.
2 Likes
I built the windows only tool chain in an Ubuntu VM under win10. Building the tool chain took, I think, a few hours. Once it’s built it’s pretty easy to build your plugins. Did not seem to take much longer than a native win build, so like a couple of minutes?
This was all with the v1 tool chain, but I don’t think it’s changed much.
Sorry to read you are having so much trouble getting systems to work.
But please remain your sanity
No need to drive yourself up the wall into a burn out.
Yes the plugins in the library need a fix, but we will wait as long is takes for you to get it done right.
All is good 
6 Likes
Will use the toolchain to compile the linux versions from a linux VM… My virtual machine is so slow than I’m afraid yet by the announced “few hours”…
@Eurikon I shoud stop and take a break but I’ve a serious problem with failure acceptation and will probably only find tranquility when all will be done.
1 Like
OK make toolchain -lin doesn’t work here. I don’t want even to look why, 3 wasted days are enough for me. So, which ubuntu version do I have to install on my VM to be able to compile wtiheout the toolchain (and get the plugins working on old distros)?
Sorry to hear you’ve got such hard time building the toolchains. Use Ubuntu 16.04.7 LTS (Xenial Xerus) for best compatibility for Linux plugin users.