Code that was able to compile and build under the old extension, yields the error that says it can’t find gpiod.h
Hi @Evets ,
“gpiod.h not found” means that the libgpiod-dev package is not installed in your SDK container (the one that compiles your code). You have to add it in torizonPackages.json as instructed in this article:
You also have to include libgpiod2 to run your code in the release container.
Follow the instructions from the link above and see if this helps you.
Best regards,
Lucas Akira
I added this but now I get an error when restarting VSCode, "Unable to load schema from ‘debian://schemas/packages’: cannot open debian://schemas/packages.
Where would this file exist?
I am also getting this error when I start VSCode:
Unable to resolve configuration with compilerPath “aarch64-linux-gnu-g++”
It is connected to my verdin board and is set as the default.
I also added libgpiod2, but I still can’t compiler because it can’t find gpiod.h.
Steve
Hi @Evets ,
Unable to load schema from ‘debian://schemas/packages’: cannot open debian://schemas/packages.
I was able to reproduce this warning message when starting VSCode with torizonPackages.json selected: Apparently the package name auto-completion doesn’t start correctly if torizonPackages.json is opened before the extension loads completely, leading to the warning message you saw.
This shouldn’t cause any compilation or build issues, though.
Unable to resolve configuration with compilerPath “aarch64-linux-gnu-g++”
Is this a warning message similar to the previous one?
Just to be sure, is your torizonPackages.json similar to this one:
{
"deps": [
"libgpiod2"
],
"devDeps": [
"libgpiod-dev"
]
}
If torizonPackages.json is like that and you still can’t build your project, can you share your Dockerfile.sdk?
Best regards,
Lucas Akira
Hi @lucas_a.tx ,
Sorry for the delay, was up fishing in a local lake last week.
The problem when I get the error is when I try to build (compile) the folder. Mine actually had both files above in both sections. I have made it like yours, but the problem still exists.
Also, at the moment, for some reason, when I do shift-cntrl-B, it thinks I am doing a cmake build not a makefile build.
Also, it is complaining that it can’t set the permissions on the .conf/id_rsa file to 0400. The folder is not in a ubuntu directory, it’s in a shared Windows folder, but it should not be an issue.
The contents of my dockerfile.sdk is:
ARGUMENTS --------------------------------------------------------------------
ARG CROSS_SDK_BASE_TAG=3-bookworm
Board architecture
arm or arm64
ARG IMAGE_ARCH=
BUILD ------------------------------------------------------------------------
FROM torizon/debian-cross-toolchain-${IMAGE_ARCH}:${CROSS_SDK_BASE_TAG}
deps
RUN apt-get -q -y update &&
apt-get -q -y install
# ADD YOUR PACKAGES HERE
&&
apt-get clean && apt-get autoremove &&
rm -rf /var/lib/apt/lists/*
deps
automate for torizonPackages.json
RUN apt-get -q -y update &&
apt-get -q -y install \
DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
# __torizon_packages_dev_start__
# __torizon_packages_dev_end__
DOES NOT REMOVE THIS LABEL: this is used for VS Code automation
&& \
apt-get clean && apt-get autoremove && \
rm -rf /var/lib/apt/lists/*
WORKDIR /app
Hi @lucas_a.tx ,
Also, this morning after I did a computer update, I no longer see the powershell come up as I start VSCode.
Is this the new normal?
I copied the folder over to a wsl2 directory, and the powershell comes up now, but didn’t affect the make result that I do in a local terminal. Still doesn’t build if I do the shift-cntrl-B.
Steve
Hi @Evets ,
From the Dockerfile.sdk you provided it looks like the dependencies listed in torizonPackages.json aren’t being applied: they should be present between
# __torizon_packages_dev_start__ and # __torizon_packages_dev_end__.
You said you were trying to build the project with shift+ctrl+b , but as far as I’m aware the extension V2 doesn’t set a default build task associated with this shortcut. I believe the task being executed with this shortcut is either not from our extension or it skips some necessary steps like applying the dependencies from torizonPackages.json when building the SDK container.
Also, at the moment, for some reason, when I do shift-cntrl-B, it thinks I am doing a cmake build not a makefile build.
At the time of writing this the extension V2 doesn’t have a CMake template, so I don’t think it is affecting this aspect in particular.
Instead of using ctrl+shift+b, can you try building your project by trying to debug it as instructed in this article:
Running a debug session ensures that all build steps are correctly executed.
Also, it is complaining that it can’t set the permissions on the .conf/id_rsa file to 0400. The folder is not in a ubuntu directory, it’s in a shared Windows folder, but it should not be an issue.
About creating a project inside or outside the WSL2 partition, I’ll confirm this with the extension team.
Best regards,
Lucas Akira
Hey @Evets
although it is possible to use the Windows file system for development, the performance loss is considerable.
See note here: Get started with Docker containers on WSL | Microsoft Learn
Always store your code in the same file system that you’re using tools in. This will result in faster file access performance. In this example, we are using a Linux distro (Ubuntu) and want to store our project files on the WSL file system
\\wsl\. Storing project files on the Windows file system would significantly slow things down when using Linux tools in WSL to access those files.
Another point is that the R&D team follows this recommendation and only performs tests on the Linux file system. In version v2.1.0 it is no longer possible to create projects in /mnt, to ensure that users do not use the Windows file system.
About the:
“can’t find gpio.h”
I’m not sure if you are gettin this error only locally or from the cross-coompile container image.
Coult you please send a print of the screen with the error please?
About the:
torizonPackage.json
The packages from torizonPackages.json are installed only inside the containers, but the VS Code will seek for a gpio.h on your development environment. So, you will need to also install the package on your WSL 2.
In a new WSL 2 terminal make sure to also install the dev packages:
sudo apt install libgpiod-dev
These will be used only for the VS Code auto-completion. For the build of the application, that runs inside a container, it will be used the packages from torizonPackages.json.
About the:
shift-cntrl-B
There is no default build task because this depends on the architecture of the target, then you need to choose the right one from the Run and Debug and run the debug session.
Looking forward to your return.
BR,
Hey @Evets
also, please send us the logs from:
This will be useful to figure out unexpected behaviors
Hi Matheus,
Just so you understand what I have done to start the project:
- launched VSCode from my wsl Ubuntu ternminal.
- created a new project on the Linux file system, using the C++ template.
- In filling out the values for the project, I was confused about what I should put for a new of the docker container. I picked one of my 4 containers that is shown in Docker, but I don’t know if it’s the right one. I have the following containers: Registry, infalliblie_wing, elegant_lichterman and brave_diffie. None of these say anything about arm64. I do have some images that do, and I have one that is based on brave_diffie that cross-toolchain-arm64-brave-diffie name.
- After I created the project, I added my files in src and includes directories.
- used my Makefile with appropriate changes to get it to compile because even when I have my dev board connected, it wants to build an amd64 version.
- with the sudo apt install libgpiod-dev I get this message:
“/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link”
It doesn’t say it’s an error, so not sure if it installed correctly or not. I am running Ubuntu 20.04.
It does run the powershell when I start VSCode, and I get no errors.
When I open a terminal for the dev board, it just opens a local terminal and while it compiles with the correct arm gcc, it still won’t find gpiod: /usr/lib/gcc-cross/aarch64-linux-gnu/9/…/…/…/…/aarch64-linux-gnu/bin/ld: cannot find -lgpiod.
It doesn’t seem to be using the container I put in the questions when I first did this, it has the name in the list, but onlly the “registry” container is actually running.
Any more help would be great!
Thanks,
Steve
Hey @Evets
In filling out the values for the project, I was confused about what I should put for a new of the docker container. I picked one of my 4 containers that is shown in Docker, but I don’t know if it’s the right one. I have the following containers: Registry, infalliblie_wing, elegant_lichterman and brave_diffie. None of these say anything about arm64. I do have some images that do, and I have one that is based on brave_diffie that cross-toolchain-arm64-brave-diffie name.
The docker service name input is for the Docker image that will be created, not for already created or running, you can put any name that is related to your project.
with the sudo apt install libgpiod-dev I get this message:
“/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link”
It doesn’t say it’s an error, so not sure if it installed correctly or not. I am running Ubuntu 20.04.
It does run the powershell when I start VSCode, and I get no errors.
Without all the logs I can’t help you, appears that you development host is on some way “corrupted”, but I can’t say without reading all the logs. Please send all the logs from your apt install attempt.
BR
Hi @matheus.tx,
Apparently, it can only be lower case letters, which seems a really weird limitation.
Here is the output and logs when trying to create a new project:
Output:
08-07 06:40:52.375] Activating ApolloX Torizon …
[08-07 06:40:52.375] Telemetry is enabled
[08-07 06:40:52.375] Extension collects completely anonymous telemetry data about templates usage. Participation in this anonymous program is optional, and you may opt-out if you’d not like to share any information. Check: https://github.com/toradex/torizon-experimental-torizon-ide-v2-docs/blob/main/USAGE-DATA.md#opt-out
[08-07 06:40:52.376] Telemetry allows us to accurately gauge templates usage. This data will help us to focus better on the most used templates, adding new features and putting effort in the right place.
[08-07 06:40:52.376] Resolving host IP address …
[08-07 06:40:52.758] Host IP address OK
[08-07 06:40:52.792] Docker installed OK
[08-07 06:40:53.028] Docker running OK
[08-07 06:40:53.116] Docker compose OK
[08-07 06:40:53.143] PowerShell OK
[08-07 06:40:53.174] git OK
[08-07 06:40:53.190] dig OK
[08-07 06:40:53.204] avahi-resolve OK
[08-07 06:40:53.227] nmap OK
[08-07 06:40:53.247] iputils-ping OK
[08-07 06:40:53.262] file OK
[08-07 06:40:53.282] sshpass OK
[08-07 06:40:53.301] net-tools OK
[08-07 06:40:53.301] Cloning project templates
[08-07 06:40:53.319] Project templates clone OK
[08-07 06:40:53.338] Checkout templates repo to v2.1.0 OK
[08-07 06:40:53.340] Checking connected devices …
[08-07 06:40:53.341] Scanning Torizon devices …
[08-07 06:40:53.352] Configuring debug id_rsa …
[08-07 06:40:53.352] Debug id_rsa OK
[08-07 06:40:53.353] ApolloX Torizon extension activated
[08-07 06:40:53.392] Checking host ip sanity …
[08-07 06:40:53.970] Host ip is OK
[08-07 06:40:53.989] Device 192.168.12.185 set as Docker Host
[08-07 06:40:56.049] Debian bookworm packages list load OK
Container Runtime: docker
Run Arguments: --rm --privileged torizon/binfmt
Container Name: binfmt
Error response from daemon: No such container: binfmt
Container does not exists. Starting …
- Terminal will be reused by tasks, press any key to close it.
Second Log:
Container Runtime: docker
Run Arguments: -d -p 5002:5000 --restart=always registry:2
Container Name: registry
Container Exists
Container is running
- Terminal will be reused by tasks, press any key to close it.
Third log:
Checking dependencies …
openssh-client installed
sshpass installed
build-essential installed
make installed
gdb installed
g++ installed
All packages already installed
At this point I’m done with the setup. as you can see it is connected to the Dev board and all is well. However, there is nothing about doing a container build, but i get this error about the container Name “binfmt” that it can’t find.
At this point I’m done with the setup. as you can see it is connected to the Dev board and all is well. However, there is nothing about doing a container build. and if I do a build it is for x86, not an arm build. The arch =: in the Makefile is not set to anything.
I started a container build which I didn’t see as an option before, I was assuming this would be done automatically as part of the setup. Here are the logs for this:
Docker start logs.txt (39.3 KB)
Doing the same steps again, doesn’t show the container build option, and I’m not sure why, but I will tell you this:
in the directions on the website, it says you must only install the build on the Windows side, not in WSL. However, when I launch in that configuration (launching from wsl), it comes up with a Windows directory as the default, not /home/username. It also doesn’t run any powershell script. So, I am not sure what to make of this. I currently have VSCode installed in WSL and on the windows side. I’ve uninstalled both and tried just the windows side, and when I run that from the wsl, it is the same. When I launch it from the WSL side, I get the error saying I should launch it from the windows side.
Steve
Hi @matheus.tx ,
I uninstalled VSCode both on Windows and on WSL (Ubuntu 20.04). Then I installed windows VSCode and ran it from WSL. It did some updates, but then came up. I went to the Toradex extensions, but it is grayed out because it thinks it’s being run from windows. I tried restarting it, but still got the same issue. The WSL extension was already installed, so I tried to connect to WSL in VSCode. Finally it worked, but it doesn’t show up on the bottom like they show it in the extension.
So then I was able to install the ApolloX extension. I created a new project and used C++. It connected to the dev board.and I set it as the default.
However, when I make, it still wants to make an ARCH=x86_64 version, not an arm64 version.
Steve
However, when I make, it still wants to make an ARCH=x86_64 version, not an arm64 version.
I believe the debug architecture defaults to x86, but you need to change it to the appropriate target architecture as shown here: Remote Deploy and Debug Projects | Toradex Developer Center
Best Regards,
Jeremias
@jeremias.tx ,
@matheus.tx,
@lucas_a.tx
OK, I’ve solved all my compile/run problems, but I am having issues with my spi device. I can open it but can’t seem to send anything.This worked with the old extension. Am I missing something?
Thanks,
Steve
Could you please open a new thread with this new issue including details and information regarding it.
Best Regards,
Jeremias