Hi everybody, trying to figure out how to build my project on Windows after finishing the build on macOS. I’m completely new to Windows, so likely my problem is related to ignorance or setting something up incorrectly. I’m getting this error when I build on Release mode, ARM64 architecture. Looks like a command involving the Manifest VST3 Helper is failing.
Rebuild started at 6:45 PM...
1>------ Rebuild All started: Project: Nudistort_VST3, Configuration: Release ARM64 ------
1>include_juce_audio_plugin_client_VST3.cpp
1> Creating library C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\Nudistort.lib and object C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\Nudistort.exp
1>Generating code
1>Finished generating code
1>Nudistort_VST3.vcxproj -> C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\Nudistort.dll
1> 1 file(s) copied.
1>Deleted file - C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\Nudistort.vst3\Contents\Resources\moduleinfo.json
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: The command "copy /Y "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\\Nudistort.dll" "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\\Nudistort.vst3\Contents\win\Nudistort.vst3"
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: del /s /q "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3\Contents\moduleinfo.json"
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: if not exist "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3\Contents\Resources\" del /s /q "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3\Contents\Resources" && mkdir "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3\Contents\Resources"
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3 Manifest Helper\juce_vst3_helper.exe" -create -version "1.1.4" -path "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3" -output "C:\Nudistort\Builds\VisualStudio2022\ARM64\Release\VST3\/Nudistort.vst3\Contents\Resources\moduleinfo.json"
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: :VCEnd" exited with code 1.
1>Done building project "Nudistort_VST3.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
========== Rebuild completed at 6:46 PM and took 45.120 seconds ==========
I had a previous linker error on ARM64 architecture where the file Nudistort.lib couldn’t be linked. Followed the advice from a forum post and added this filename to the Projucer’s “External Libraries to Link” and “Extra Library Search Paths” fields, which seemed to fix it, but now I’m getting this error. Thanks so much, any insight is appreciated!
1 Like
Take each of the commands to the command line and try to get them completed successfully by hand, first. There is a lot that can fail in that batch - the copy, the del, the check for existence … code 1 just means the .bat terminated. Which of these commands is failing? You should be able to check them at your own prompt …
1 Like
Huh, great idea! I decided I’d try building on x64 architecture instead of ARM64 architecture, and it built successfully on Release mode with no errors. However, the resulting vst3 crashed any DAW instantly upon startup. To debug it, I tried building again on Debug mode on x64 architecture. However, I got the same command failure I got before, so I followed your suggestion and attempted to run each command individually on the terminal. It appears that each one ran successfully!
The juce_vst3_helper.exe command took a few seconds to run, so I take that to mean that it was doing something, even though there was no output. Any further ideas about what could be going wrong? Thanks so much.
Look closer at the paths in the post build steps \ /
Rail
Hmm, yeah I noticed that. I’m not sure that that’s the real cause, because the commands ran just fine on my machine. And some sleuthing revealed that Windows essentially ignores / characters in situations like this. I checked by deleting these characters from the commands I ran on the terminal, and the commands worked the same way they did before. I also tried deleting the extraneous \ in one of the paths, but this didn’t make a difference either. So I don’t think that’s the issue. And if it was, I’m not sure how I would fix it.
As for an update on where I’ve gotten with this problem, I figured out that an uninitialized pointer deep in my code was causing the error, and that if I initialized that pointer, the error would go away and the build would work just fine. I used this to build successfully for x64 architecture.
However, I want to try building for ARM64 architecture, since I’m doing these builds within Parallels on an M1 mac (I’m now thinking that this could be the source of my troubles), and x64 builds have poor performance on my machine. I found I could not complete any ARM64 builds, even with a completely clean Projucer project - I get the same errors I got above.
Here’s how to reproduce: start a clean Projucer project inside a Parallels instance on a mac, selecting ‘Audio Plug-In’ as the template and ARM64 as the architecture. Don’t edit anything, and try to build in Debug or Release mode. For me, the build fails and I get this set of errors. If this also fails on genuine Windows, this would be a more serious bug.
I’ll have access to a bona fide Windows machine later this week, so I’ll see if the problem is related to Parallels or not. As I understand Parallels is a pretty complete emulation, so I’d be surprised if this was the cause, but there could easily be something I don’t understand that makes it break. Everything else about JUCE has been working perfectly inside Parallels until now, and my x64 builds appear to work great. Will update once I have access to that machine.
I know I may open a new issue, but my problem is really close to what you experienced: I’ve got the exact same errors and building informations when opening the output of the terminal.
In fact, when building the standalone plugin, it works, but when it comes to building the VST3, I have this problem. Another important point is that I use an external library (Eigen), and the generation fails when I want to compile the plugin using a sub-package of this library (Eigen/KLUsupport), which depends on other packages and libs (some packages from suitesparse), but when I use the “default” package, the plugin can be compiled. Does anyone now what to do ?
I’m on Windows 11, MVSC 2022 17.8
Hm, interesting. For me, there was really an uninitialized pointer in the code that I had to go find and fix with git bisect. Could be a bug in that subpackage of Eigen, but could it also be how you’re using it? Does it compile if you include that package but don’t use it at all in your code? If so, can you isolate the line of code that breaks it?
Actually I can compile a VST3 plugin if I write #include <Eigen/KLUsupport> and don’t declare any object from this library, so it compile if I include the package without using it.
Concerning where I can found the line that breaks it, I don’t know how to proceed. Do you know the main step to debug the plugin ? Usually when I debug I do it with the standalone plugin (which may not be a good practice…
In fact, what I find “mystical” is that this is a build error and not a compiler error, I mean the shared code is still compiled whether I use Eigen/KLUsupport or not, but the VST3 is not built correctly if I use this sub-package in my code (when I use the include and use it in my code).
If you can include the library and build the VST3, then see if you can declare an object from the library. If you can do that, then see if you can perform operations on that object - etc. Eventually, you’ll see at which line things break. Alternatively, if you added this functionality over time, you can use git bisect, which is a much quicker way of figuring out these things as long as you make frequent commits.
This kind of debugging shouldn’t be fundamentally any different than your standalone debugging, since you’re looking for a build error. I would recommend, in the future, building all targets from the start when you’re debugging so you can be sure that they all build correctly.
