Yes, I am aware of the need for rebuilding of the SDK, and I do it quite often. And yes, I have libgpiod-dev:arm64 in the extension under “Custom Properties/devpackages” and have had that since the beginning. I still can’t get it to find the gpiod.h file.
That’s strange. If you did all of this and gpiod.h still can’t be found then something could be wrong with the extension itself, with Docker, with the SDK container or even with the Dev containers extension. Can you send a screenshot of your entire VSCode window when the gpiod.h: No such file or directory error occurs, and with the extension settings being shown?
I have to ask, are you using the same target as I have? iMX8m plus? Up until now, I’ve been able to get most things to work, although I had some trouble with CAN since I couldn’t get it to load the can-dev lib as specified in the example, but I haven’t tried too much with that. I don’t have any actual calls for GPIO statements in my code yet,. as that was the next step.
I deployed the sample gpiod app I mentioned before on a Colibri iMX8X running TorizonCore 5.7.0, but all the procedures in the extension should be the same as on a Verdin iMX8M Plus, given that both SoMs are ARM64.
I went back though my docker checks to verify everything is working, and this is where things get weird. Under Configure Build Environment for Torizon Containers | Toradex Developer Center
it says the return for this command “docker run --rm -it arm64v8/debian arch” should be only “aarch64”, but when I run it, I get that, but also some pretext: docker run --rm -it arm64v8/debian arch WARNING: The requested image’s platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested aarch64
Which is what I am seeing when I try to run debug my target. Is this a clue? What would cause this? I didn’t get this originally, I’m pretty sure.
This warning message appears when building a docker image with a different architecture than the host system, which is expected when trying to build containers designed for ARM systems on your host machine, which is x64. We do this to build, through emulation, the ARM containers that will be deployed to your Verdin iMX8M Plus, and it shouldn’t be a cause for concern, at least not this message by itself.
Hi @lucas_a.tx ,
OK, I played around a bit with an Hello World! example code. Initiallly, I had the same problem. But I changed a few settings in the Torizon extension, and now it is finding the gpio.h file and compiling. At this point, I don’t know why it is working. I added in the devices, the /dev/gpiochip0-5 (one per line), and then it started working. I did the same to my other project, but there is no difference, it still fails to build. I’ve even added the additional libraries i needed for the other build to the working one and it still works.
in doing a comparison between the builds, the only thing I thought was a bit weird, was in the settings.json file this line was present under “files.associations”:, which is a bit weird:
“gpiod.h”: “c”. My other project has this under “files.associations”:
“limits”: “cpp”,
“type_traits”: “cpp”
and nothing with gpiod.h
Also, my other project is a C++ project not a C project. Could this be the issue?
Also, can you outline the specific settings in the configuration that affects the container that gets built? As a work around, can I point to the working container as a starting point and have it work or will it not work because it’s a C project?
OK, I played around a bit with an Hello World! example code. Initiallly, I had the same problem. But I changed a few settings in the Torizon extension, and now it is finding the gpio.h file and compiling. At this point, I don’t know why it is working. I added in the devices, the /dev/gpiochip0-5 (one per line), and then it started working. I did the same to my other project, but there is no difference, it still fails to build. I’ve even added the additional libraries i needed for the other build to the working one and it still works.
Good to know that you managed to get your code working by creating a new project!
Also, my other project is a C++ project not a C project. Could this be the issue?
Also, can you outline the specific settings in the configuration that affects the container that gets built? As a work around, can I point to the working container as a starting point and have it work or will it not work because it’s a C project?
I don’t think this is causing the issue, because my gpiod test project made in C works fine, and its settings.json only has these lines:
The last image you posted shows that with your non-working project VSCode isn’t connected to a dev container, and so it can’t really find the packages added in devpackages. In fact, the extension isn’t being initialized correctly: see the Torizon: Initializing... message at the bottom of the window. That’s what is causing the problem: for some reason the extension can’t start correctly when opening your non-working project.
If you want, you can send the source code of your project so we can try to run it on V2 (ApolloX). If don’t wish to make it public you can send it to our support email instead (support@toradex.com).
HI @lucas_a.tx ,
I can’t send any code as that is company policy. I will try a few more things to see if I can narrow it down more. Another thing I know is that even though it’s a makefile project, it comes up quite often (like every time I rebuild the sdk), asking about configuring cmake, which it isn’t and thus it has a setting “cmake.confgureOnOpen”: false. My settings.json looks like this:
{
“torizon.configuration”: “debug”,
“torizon.appfolder”: “appconfig_0”,
“files.associations”: {
“limits”: “cpp”,
“type_traits”: “cpp”
“gpiod.h”: “cpp”
},
“cmake.configureOnOpen”: false
}
Is there any way you can tell me what triggers putting in the gpiod.h file to the container? It just seems there there is some weird combination that is causing the issue here.
As for the container build issue, I briefly see a red line go by when building the sdk, but I can’t see what it is as it goes by too fast and it just says there is an “unknown error”, and there is no history at that point that I can look back to.
Thanks,
Steve
P.S. After I rebooted my computer, Docker no longer has any images or containers showing. I have no idea what happened.
@lucas_a.tx ,
The error was that it decided it couldn’t write to the target directory. The directory was for some reason owned by root, and also under work in the local file it had an additional directory and executable which was old, so I deleted it. But it still will not pull in the gpiod.h file. If I comment that out, it compiles and runs just fine and I can step through code.
I made the c_cpp_properties.json files match as well as settings.json, extension.json and tasks.json. Launch.json and torizon-vscode-settings.yaml files match except for the exe names. The only real differences now are the docker containers and config.yaml which has name and key differences.
Hi @lucas_a.tx
I figured out the problem. It was using another compiler, (aarch64-linux-gnu-g++) not the default one, (aarch64-linux-gnu-cpp).
However, when I tried to link my program, it gave me this error:
aarch64-linux-gnu-cpp: fatal error: too many input files
I changed it back to using the g++ version and took a look at the includes that were in the original makefile. There were things that didn’t need to be there. And then it found gpiod.h. Not sure why that made a difference.
If I understood everything correctly, you managed to solve your initial issue i.e. gpiod.h not being found, and you now trying to figure out what caused it, is this correct?
I believe the header file wasn’t being found because of what I said previously: Given that your first project wasn’t connected to the dev container, VSCode wasn’t inside the environment that has the libraries defined in devpackages. As for why the project wasn’t connect to the dev container in the first place, it is difficult to know for sure without more info.
Keep in mind that when you open a C/C++ project folder on V1 of the extension you aren’t connected to the dev container right away, you have to click on a pop-up message prompting you to connect to it.
If your initial problem is solved, can you mark the relevant post as the solution? Otherwise feel free to reply back.
Hi @lucas_a.tx ,
To be perfectly honest, I don’t know why the gpiod.h wasn’t there when I compile. Because when I backed out my changes that I thought made it work, it still worked.
It could be related and is related to an include file that defined some things, that might have affected the compiler name, but I don’t understand when I went back to what I had, why the problem didn’t return.
I am pretty sure that the extra includes caused the issue, so not a normal thing for probably any one else.
I will say, it is not clear as to what items in the torizon extension affect the torizon container that the app runs in, and what affects the compiling mechanism/local container on the build machine. It seemed pretty straight forward for SPI, but gpio wasn’t the same, and now I’m having issues with CAN which I did have working where I could execute CAN commands, but now they aren’t found. I’m putting in another ticket for this. CAN information on your site seems very spotty and only talks about really working with python and command line.
