That’s because this forum uses markdown. Use triple back tick fences (```) around blocks of code (like makefile quotes), and use single back ticks (`) for inline literals. To escsape a single char like an angle bracket, use a backslash.
2 Likes
Hi Eric, I hope you’ve been well. Maybe you might be able to lend me a hand here. I’m updating the toolchain to 2.5.2, and have run into a bit of a snag. I’m getting this error message in terminal, and I think it may have something to do with tag number being 12 in my rack-plugin-toolchain image in docker, when the latest MAKE file for the toolchain is 15. This is the message I’m getting:
Unable to find image 'rack-plugin-toolchain:15' locally
docker: Error response from daemon: pull access denied for rack-plugin-toolchain, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.
It’s unclear to me how to update the image for the toolchain in Docker. As far as I was concerned, I didn’t have to do anything new with Docker after pulling the toolchain update, and cleaning the sdks and redownloading them.
Have you updated your toolchain yet, and possibly have any suggestions regarding what I may be missing and possible steps to get back up and running?
If anyone else has any suggestion, it would also be greatly appreciated. Thank you 
Edit:
Okay, I think I managed to sort it out, as changing the tag from 12 to 15 resulted in a successful build. Although, changing the Docker Image Tag number did seem to create a second Docker image, and I’m not sure if I should remove the first image with the tag 12, as I have two images now.
These were the steps needed to create a second image with the proper tag. I’ll leave this here for future reference and/or if anyone else runs into this issue and is as unfamiliar with Docker as I am:
- List the images on your system using the command
docker images.
$ docker images
- Identify the image you want to retag, and take note of its IMAGE ID.
REPOSITORY TAG IMAGE ID CREATED SIZE
my-image latest 0d120b6ccaae 3 weeks ago 122MB
- Use the
docker tagcommand to retag the image. ReplaceIMAGE_IDwith the ID of the image you want to retag andNEW_TAG_NAMEwith the new tag name you want to assign to the image.
$ docker tag IMAGE_ID NEW_TAG_NAME
- For example, to retag the image
my-imagewith ID0d120b6ccaaetomy-image:v2, you would run the following command:
$ docker tag 0d120b6ccaae my-image:v2
- Verify that the tag has been changed by listing the images again.
$ docker images
You should see the image with its new tag listed.
Hi @CircadianSound, first, you have to differentiate between two things:
- The toolchain version
- The Rack SDK version
The toolchain version is equivalent to the Docker image version and it is defined in the Makefile. The toolchain version represents the state of the toolchain components, for example compiler versions.
The Rack SDK version is independent of the toolchain version. The toolchain can remain at one version while the Rack SDK can be updated independently of the toolchain.
If the toolchain updates, i.e. the toolchain version is incremented in the Makefile, you generally should rebuild the toolchain, which will result in an updated Docker image tagged with the toolchain version. The Makefile will then use the new Docker image for the plugin builds.
To update your build environment to the latest tested Rack SDK, you can run the following commands:
make rack-sdk-clean
make rack-sdk-all
This will download the latest Rack SDK as defined in the Makefile without having to rebuild the Docker image.
The Makefile defines both the latest Rack SDK and the toolchain version. Depending on which version updates if you pull a new version of the repository, you have to understand, which process to execute. However, if you rebuild the toolchain image, the Rack SDK will be updated as well. Therefore, if you are unsure what to do, rebuild the Docker image.
Note that you can do what you did, which is retag the old toolchain Docker image with the new toolchain version and make it match the Makefile. However, if the toolchain version updates, it is recommended to rebuild the toolchain. Proceed at your own risk.
3 Likes
Hi @cschol, thank you for replying here with this information to consider.
After pulling the latest toolchain, cleaning out the SDKs and making them update to 2.5.2, I tried to build my plugin. That’s when I ran into a snag. I wasn’t sure what to do, and made a leap of logic based on the error message. You’re saying it’s recommended to build the toolchain again, but retagging the docker image with the updated toolchain version is fine, albeit risky.
If it’s building properly at the moment, do you think I’m fine over here? I rather not run the lengthy process again if I don’t have to, unless you highly advise against what I did. If I encounter build failures along the way, or experience anything else unexpected, at least I’ll now know that the retagging might be the culprit. This thread has helped me a lot with getting this far, and I don’t want to undermine good advice. In the future I may just have to do this, and rebuild the toolchain. I appreciate the warning to be careful here, and consider your recommendations. Are there any other risk factors that I should consider here for next time?
A question though. In the meantime, is it safe to delete the docker image for the toolchain that’s tagged as 12, and keep the more current image that’s tagged as 15? Just to keep things clean and not have two docker images for the toolchain?
Thanks again Christoph, I appreciate all the help you’ve provided so far 
Developers,
The VCV Rack Plugin Toolchain has been updated for the release of Rack 2.6.3.
NOTE: Due to the update of the macOS SDK, a new macOS SDK tarfile must be provided to the build process when rebuilding the toolchain. See README.md for details on how to obtain the SDK tarfile.
Changelog:
- Update to macOS SDK 12.3 (last version to support the Rack minimum macOS 10.9 version).
- Starting with 2.6, Rack SDK for macOS is now split in separate zip files for x64 and arm64.
- Update to latest versions of toolchain dependencies (crosstool-ng, osxcross).
4 Likes
The macOS SDK 12.3 is included in Xcode 14.0.1 or Xcode 13.4.1. Added links to README.
4 Likes
Hello!
I updated my Rack toolchain to the one released a couple of days ago with the 2.6.3 SDK and built a new Docker image to accommodate it.
The toolkit build works fine; minus a warning:
warning found (use docker --debug to expand):
LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 2)
After the image is done (boy, that takes a while…) my test plugin for Windows and Linux appears to build properly using that image; but… the Windows plugin crashes Rack when trying to open the module browser; the same plugin built for Linux works properly; I can’t test Apple plugins; but the final purpose of the image is to use it in my workflows and plugins for Apple are built using a different path, so it doesn’t really matter.
Using the standalone SDK under Windows produces a plugin that works as intended (it’s a plugin with a single test module that does mostly nothing).
The plugin also works as intended with my local Rack 2.6.3 build, under Windows and Linux.
The only ones that crash are the ones built using the local and remote Docker images.
My 2.5.2 local Docker image produces a proper plugin.
Am I doing something wrong or missing something? Don’t expect it to make a difference; but the local Docker host is Manjaro Unstable (otherwise Valgrind doesn’t work…) and the Github host is Ubuntu latest.
Thanks in advance for any help
I used to have a problem that my dev builds worked fine in windows, but the official ones crashed. Probably not related……
Fixed the warning in the Dockerfile. Thanks.
Can you provide a backtrace or log for the plugin crash on Windows?
Sure! Here’s a backtrace:
#0 0x00007fffe3a3730f in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x00007fffe3a02197 in ntdll!EtwLogTraceEvent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0x00007fffe3a35678 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\WINDOWS\SYSTEM32\ntdll.dll
#3 0x00007fffe39ed126 in ntdll!EtwLogTraceEvent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x00007fffe396c334 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5 0x00007fffe396b001 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6 0x00007fffe0ef364b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll
#7 0x00007fff5ae1f12b in plugin!_ZN21SanguineTestBedWidgetC1EP15SanguineTestBed () from D:\msys64\home\Bloodbat\rack\plugins\SanguineTest\plugin.dll
#8 0x00007fff5ae82e84 in plugin!_ZZN4rack11createModelI15SanguineTestBed21SanguineTestBedWidgetEEPNS_6plugin5ModelENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEN6TModel18createModuleWidgetEPNS_6engine6ModuleE () from D:\msys64\home\Bloodbat\rack\plugins\SanguineTest\plugin.dll
#9 0x00007fff4f51d594 in rack::app::browser::ModelBox::createPreview (this=0x28559f0) at src/app/Browser.cpp:207
#10 rack::app::browser::ModelBox::draw (this=0x28559f0, args=...) at src/app/Browser.cpp:219
#11 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284d510, child=0x28559f0, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#12 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284d510, args=...) at src/widget/Widget.cpp:280
#13 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284d440, child=0x284d510, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#14 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284d440, args=...) at src/widget/Widget.cpp:280
#15 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284d160, child=0x284d440, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#16 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284d160, args=...) at src/widget/Widget.cpp:280
#17 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284d0a0, child=0x284d160, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#18 0x00007fff4eec9982 in rack::widget::Widget::draw (this=this@entry=0x284d0a0, args=...) at src/widget/Widget.cpp:280
#19 0x00007fff4eec18ff in rack::ui::ScrollWidget::draw (this=0x284d0a0, args=...) at src/ui/ScrollWidget.cpp:68
#20 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284c430, child=0x284d0a0, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#21 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284c430, args=...) at src/widget/Widget.cpp:280
#22 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284c3a0, child=0x284c430, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#23 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284c3a0, args=...) at src/widget/Widget.cpp:280
#24 0x00007fff4eec9868 in rack::widget::Widget::drawChild (this=this@entry=0x284b340, child=0x284c3a0, args=..., layer=layer@entry=0) at src/widget/Widget.cpp:311
#25 0x00007fff4eec9982 in rack::widget::Widget::draw (this=0x284b340, args=...) at src/widget/Widget.cpp:280
#26 0x00007fff4eecee84 in rack::window::Window::step (this=this@entry=0x28581e0) at src/window/Window.cpp:512
#27 0x00007fff4eecf208 in rack::window::Window::run (this=0x28581e0) at src/window/Window.cpp:421
#28 0x00007ff624372dcb in main (argc=2, argv=0x14fd80) at adapters/standalone.cpp:275
Might need to see what your TestbedWidget is doing (source code).
have you run under asan or valgrind?
Yep, and, as expected, Valgrind shows nothing for it.
The “exciting” widget:
struct SanguineTestBedWidget : ModuleWidget {
SanguineTestBedWidget(SanguineTestBed* module) {
setModule(module);
setPanel(Svg::load(asset::plugin(pluginInstance, "res/testbed_30hp_blank.svg")));
addChild(createWidget<ScrewBlack>(Vec(RACK_GRID_WIDTH, 0)));
addChild(createWidget<ScrewBlack>(Vec(box.size.x - 2 * RACK_GRID_WIDTH, 0)));
addChild(createWidget<ScrewBlack>(Vec(RACK_GRID_WIDTH, RACK_GRID_HEIGHT - RACK_GRID_WIDTH)));
addChild(createWidget<ScrewBlack>(Vec(box.size.x - 2 * RACK_GRID_WIDTH, RACK_GRID_HEIGHT - RACK_GRID_WIDTH)));
}
};
I posted the source above; the testbed is actually what I use to accomplish a bit of what you were asking about in another thread about coercing the makefile into generating developer and release builds with different modules… I just use a different plugin and copy and paste.
Quick question. The instructions for the updated toolchain build state:
“ (Just passing -j$(nproc) directly will not work due to the different build systems used in the toolchain build process.)”
Should I continue to use JOBS=4 and -j4 (for my quad core machine) as I did in previous versions of the toolchain? I learned that -j$(nproc) will automatically pass the number of cores on the machine being used, but as stated above, the instructions suggest that using -j$(nproc) won’t work.
The new toolchain version updates the Windows gcc cross-compiler from 13.1.0 to 14.2.0.
Can you try to build Fundamental with your toolchain and see if the Windows crash occurs as well?
Just using -j is not enough to instruct the build process to use a certain number of jobs. JOBS= is required as well. So you could do JOBS=$(nproc) and -j$(nproc).
Yep, I noticed that
I just built Fundamental and it does, indeed, crash. This time I didn’t open the browser: the loaded patch already had some Fundamental modules in it.
The backtrace:
#0 0x00007fffe3a3730f in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x00007fffe3a02197 in ntdll!EtwLogTraceEvent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0x00007fffe3a35678 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\WINDOWS\SYSTEM32\ntdll.dll
#3 0x00007fffe39ed126 in ntdll!EtwLogTraceEvent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x00007fffe396c334 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5 0x00007fffe396b001 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6 0x00007fffe0ef364b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll
#7 0x00007fff594ad44d in plugin!_ZN11ScopeWidgetC1EP5Scope () from D:\msys64\home\Bloodbat\rack\plugins\Fundamental\plugin.dll
#8 0x00007fff595234a4 in plugin!_ZZN4rack11createModelI5Scope11ScopeWidgetEEPNS_6plugin5ModelENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEN6TModel18createModuleWidgetEPNS_6engine6ModuleE () from D:\msys64\home\Bloodbat\rack\plugins\Fundamental\plugin.dll
#9 0x00007fff4cc2018b in rack::app::RackWidget::fromJson (this=0x27b9b50, rootJ=rootJ@entry=0x2833ba0) at src/app/RackWidget.cpp:376
#10 0x00007fff4cbceac4 in rack::patch::Manager::fromJson (this=this@entry=0x27c6460, rootJ=rootJ@entry=0x2833ba0) at src/patch.cpp:554
#11 0x00007fff4cbcf308 in rack::patch::Manager::loadAutosave (this=this@entry=0x27c6460) at src/patch.cpp:381
#12 0x00007fff4cbd1ae0 in rack::patch::Manager::launch (this=0x27c6460, pathArg=...) at src/patch.cpp:79
#13 0x00007ff624372d68 in main (argc=2, argv=0x14fd80) at adapters/standalone.cpp:259
Continuing.
warning: HEAP[Rack.exe]:
warning: Invalid address specified to RtlFreeHeap( 0000000000580000, 000000000A8D7E50 )
Thank you.
Issue has been confirmed on my test system. Investigating.
Further discussion of issue and any troubleshooting of this issue will be moved to Github.
1 Like