I’m trying to set-up a second Torizon development PC as part of preparing to demo Torizon to my team, but I’m getting an error when attempting to build the Torizon SDK container. The two PCs have the same versions of Windows, Docker, Visual Studio 2017 and the Torizon Visual Studio extension installed. They are both trying to compile the one-line hello world code which is created by default when creating a new Torizon C++ project in Visual Studio. The project has the same name and is in the same place on both PCs. But it works on one PC and fails on the other.
Both PCs success when building the application container so I think Docker is running correctly. The failure happens at the step of creating the SDK container. The error message is:
Building container...
Container has been built.
Updating SDK...Error updating Torizon SDK container.
Code: 500
Description: Internal server error
Message: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'C:\\Users\\snaddenm\\Desktop\\TorizonApp5\\TorizonApp5\\appconfig_0\\sysroot\\lib\\ld-linux-armhf.so.3'
The file in the error message is just a regular binary file on the PC that works, but on the PC with the error this file appears in the File Explorer as a symbolic link (Windows shows the type as .symlink). But I can’t open the file. What would cause that file to be interpreted as a symbolic link on one PC but not on another?
Are you using a different filesystem on the 2nd PC?
The build process works as follows:
debug container is generated, installing “-dev” packages for libraries
the container filesystem is extracted in the sysroot subfolder
relevant folders (/lin, /usr/lib, /usr/inc etc.) are copied from the local PC to the SDK container
It may be that some of the links are not supported by the filesystem on the 2nd PC or that the user does not have enough permissions to do that.
One difference that I just noticed between the PCs is that the new PC which has the problem is running Windows 10 build 1903 while the old PC where the build works is running Windows 10 build 1803. Could that be the root cause?
I also have a VM running on the new PC which contains another copy of Windows 10 build 1903 and a nested instance of Hyper-V running Docker. That VM has the same issue with failing to build the SDK. What I’ll do next is create a another VM on the new PC and install Windows 10 1803 inside it, that experiment might tell us something useful.
Both PCs are building the same project which is based on the Buster Slim 1.0 platform, with no extra libraries added. The projects were created from the standard hello world project without being modified.
Both PCs appear to build the container correctly, but when I look at the /usr/lib folder I can see that on the PC where it works there are more folders generated. The first screenshot shows the /usr/lib folder on the new PC where the SDK build fails. That folder contains 7 subfolders and the suspicious symbolic link file.
[upload|O/GX1lsm0J3ztQRJfxq/545FR3M=]
The second screenshot shows the /usr/lib folder from the PC where the SDK build succeeds. It contains many more subfolders, and the ld-linux-armhf.so.3 file is a binary file with size 104 kB rather than a symbolic link.
@valter.tx my experiment to compare Windows 10 1803 and 1903 didn’t work because Docker does not seem to work in a nested Hyper-V VM in Windows 10 1803, but it does work in build 1903. One of the reasons that I am using build 1903 is that Microsoft seem to have fixed some of the networking issues in Hyper-V in build 1903.
Which build of Windows 10 are you using when you test this?
@valter.tx I’d like to share an observation with you. I’m working with Torizon in two ways in parallel while deciding which path is best for me:
Visual Studio 2017 with the Torizon plug-in to develop in C++
Visual Studio Code to develop in C# with .NET Core
I like the approach that you took with Visual Studio Code much better because the mechanics of building and deploying the contains and the app are implemented using simple scripts in the settings.json file. That allows me to look at the scripts, learn from them, debug them and modify them.
With Visual Studio 2017 the Torizon extension is a black box and when it has a problem I don’t know how to fix it because the implementation details are hidden from me. The extension seems to have a lot of problems in my experience so far.
Would it be possible to use Visual Studio to develop C++ code for Torizon without using the Torizon plug-in and by just using simple scripts instead which are attached to build events in Visual Studio? That would let users see what the scripts do and help to debug them.
I see your point, but there are some technical reasons that explain why things work in a different way.
Unfortunately, Visual Studio does not provide the same scripting support that VSCode does, it’s designed to be extended by implementing extensions written in C/C++ or .NET.
The decision about open sourcing or not those parts is not up to me, I can raise the issue internally, but the VS integration will remain a full-blown Windows component rather than a collection of scripts, this is the way you have to implement it in VS.
Building and deploying C/C++ code from VSCode is doable, they already provide some support for that that works well for native builds (code that runs on the same machine). Supporting cross-compilation would be a different story. You will need a cross-compiler and all the libraries (what current integration nicely run inside a container) and then you need to deploy the built artifacts on the target (in a container) and debug them.
Python and .NET provide nice package managers (pip and nuget) and a compiler/runtime that runs well on most of Windows and Linux PCs. The C/C++ story is quite different and setting up a local build environment depends on your host OS/distro etc. and each library can be provided using different build methods, unless you rely on packages from a specific distro (what we do from debian).
You should also consider that, even if Microsoft marketing managed to confuse things by using similar names, Visual Studio and Visual Studio Code are two quite different products. The first one is a full-blown and Windows-only (mac version is quite limited) IDE, designed to manage complex solutions, multiple projects etc. Visual Studio Code is an “editor on steroids” (can’t find a better definition) that is natively cross-platform, supports debuggers etc. and is designed to be extended by scripts AND extensions.
Your feedback is quite useful and I thank you also for having reported the different issue you faced using our tools, I can’t promise anything about C/C++ support via VSCode, but definitely is something on our radar.
Thanks for your detailed and considered reply @valter.tx. I’ve been using Visual Studio for many, many years and I only discovered Visual Studio Code recently while working with Torizon. I do understand that Visual Studio Code is a cross-platform editor on steroids. I am drawn to wanting to use Visual Studio due to it’s familiarity and it’s support for things like different project configurations, automation, testing and so on. Visual Studio Code does seem to work very well though.
I wasn’t really asking for C++ support in Visual Studio Code, I’d be more interested in .NET Core support in Visual Studio to allow me to directly deploy and debug .NET Core code from Visual Studio on a Toradex module.
I already have my .NET Core project set-up so that I can build it for Linux and debug on a Colibri module from Visual Studio Code, and I can open the same project in Visual Studio and then build it for Windows and debug it on Windows. When running on Windows the project uses code to simulate the SOC hardware. I really value being able to run the same code on Windows and on the Colibri for development and testing. We’ve been doing that for years with Windows CE as it was easy in Visual Studio to have one configuration for Windows CE and one for Win32 so that the project could be built and run in either environment.
Hmm, that feels like an important clue @valter.tx. There is a button in the settings tool on my PC which says, “Go back to the previous version of Windows”. I’m tempted to press that button to roll back from version 1903 to 1803 and then see if the Torizon extension starts to work. But I’m nervous about taking too much risk with my main development PC (I’m taking it with me on a business trip in a couple of days and I can’t afford to break it right now).
A safer experiment might be to upgrade my older PC where the Torizon extension is working from version 1803 to 1903 to see if the extension stops working after the upgrade. That older PC is more expendable if the upgrade/downgrade goes wrong.
@valter.tx I upgraded my older PC from Windows 10 version 1803 to version 1903. Visual Studio has no problem updating the SDK on that PC with Windows 10 version 1903. So the Torizon extension does not have a problem with version 1903. Both PCs are running Windows 10 Enterprise.
There must be something else that causes the problem on the newer PC, but I can’t find the root cause.
Yes, that’s possible. The PC with the problem has a corporate virus scanner installed while the PC without the problem does not. I can’t switch off the virus scanner so I think what I need to do is visit my IT team and ask them to switch it off for 5 minutes for a quick experiment. It will take me a while to get an opportunity to be in the right place to do that though.
