Visual Studio Code extension; add thread library to build

[aigF]

Hello,

I am currently running tests on TorizonCore and its VSCode extension.
I am trying some basic C/C++ code which tests the hardware interfaces like UART, I2C etc.

My problem happens when I try to include the thread-library.

#include <thread> Results in a “No such file or directory” error message.

How do I include the thread library on the extension?
Is it correct to just add the /usr/include/** path to the c_cpp_properties.json for IntelliSense purposes?

{
“configurations”: [
{
“name”: “Linux”,
“includePath”: [
“${workspaceFolder}/",
"/usr/include/”
],
“defines”: ,
“compilerPath”: “${env:CC}”,
“cStandard”: “c11”,
“cppStandard”: “gnu++14”,
“intelliSenseMode”: “gcc-arm64”
}
],
“version”: 4
}

How do I include the library in the gcc build? just edit the build options in task.json?
Or do I have to add the library as devpackages or extrapackages?

Best regards

[jeremias.tx]

Greetings @aigF,

I did a quick test on my end. I created a single file C++ project in VSCode and added #include <thread> to the default hello-world app that gets generated. With no other changes to the default project configuration I was able to build the application with no errors.

It seems like I can’t reproduce this on my side then. I’ll need some additional information to figure out what could be wrong.

• If you do the simple test I did above, do you still get the same error?
• Did you make any configurations/changes to the project after it was generated?
• What version of VSCode and our extension are you using?
• Are you doing this on a Windows or Linux machine?

Best Regards,
Jeremias

[aigF]

Hello @jeremias.tx,

the extension is V1.3.0,
VsCode is V1.63.2.

I created a new project with the following steps:

• Torizon/C-C++: Create C/C++ application
• Makefile-based project
• arm64v8-debian-no-ssh-bullseye

No changes were made on any config file.
I merely added the include for thread to the hello-world project. It still has the same problems.
thread: No such file or directory.

I am currently running my tests on an Ubuntu 20.4 VirtualBox VM.

Best regards

[henrique.tx]

Hi @aigF !

A C++ (or C) software that uses the thread must be linked against the pthread lib.

But the way to do so depends on your project if you are using Makefile, CMake, Autotools, etc.

What you are missing, is to add the -pthread argument to your Makefile compilation command.

If you would compile your program on the terminal, it would be something like this:

g++ threaded-software.cpp -o threaded-software -pthread

Best regards,

[jeremias.tx]

In that case, if you are creating a Makefile-based project the default template produces a C-based code and Makefile.You need to do slight modifications to the default produced code and Makefile. For example changing the CC environment variables to CXX in the Makefile and such changes.

Once you’ve done these simple changes you shouldn’t be getting the “No such file or directory” error message anymore.

I assume you’re intending to work with C++ rather than C since <thread> is a C++ library.

Best Regards,
Jeremias

[aigF]

Seems like this was indeed the problem.
Editing the make-file fixed the build errors.

thanks!

[jeremias.tx]

Glad to assist!

Best Regards,
Jeremias

[billi1234]

Hey Guys…

i think i have the same problem. changing the CC environment variables to CXX in the Makefile dosnt help. I have the same problem if i use Cmake or a Makefile Project. What am i doing wrong? or it is only a Problem with IntelliSense?

[henrique.tx]

Hi @billi1234

I had no problem using CMake to build a “thread hello-world”.

Here is my exe.cpp source:

exe.cpp

#include <thread>
#include <iostream>

void foo() {
    std::cout << "oiee" << std::endl;
}

int main(int argc, char const *argv[])
{
    std::thread first (foo);
    first.join();

    return 0;
}

And here is my CMakeLists.txt (I had to add the thread):

CMakeLists.txt

cmake_minimum_required(VERSION 3.0.0)

find_package (Threads)

add_executable(cpp-thread-test exe.cpp)

set_target_properties(cpp-thread-test PROPERTIES VERSION ${PROJECT_VERSION})

target_link_libraries(cpp-thread-test LINK_PUBLIC cpp-thread-testlib Threads::Threads)
target_include_directories (cpp-thread-test PUBLIC ../lib/include)

I didn’t need to modify the c_cpp_properties.json.

And the IntelliSense is working as well:

Best regards,

[billi1234]

Thanks! but why i get the warning “aarch64-linux-gnu-gcc” not found ? Have I forgotten or done something wrong during installation or when setting up the program?

[henrique.tx]

Hi @billi1234

Can you check if your VS Code is actually running the Remote Container? You can check it taking a look at its bottom-left corner.

Not using Remote Container:

Using Remote Container:

If it is not using Remote Container, just click on the “> <” orange button and select “Reopen in Container”

---

Issue with Remote Container

If you are facing issues related to the Remote Container, rebuilding it might help you: press F1 and look for “Remote-Containers: Rebuild and Reopen in Container”

Best regards,

[billi1234]

@henrique.tx

ng the Remote Container? You can

Thanks!!

I cant see the orange “> <” in my statusbar… idont know why…

Reloading the sdk container dosnt help. I tried this a few times before. But i see that im using a Dev Container in the project bar.

[henrique.tx]

Hi @billi1234

I’m on Ubuntu 20.04… You said you are using Ubuntu 20.04 on a VM so it should be the same for us. Is it possible that you have something outdated? Here is are my version for comparison (Help > About). You can see that I installed VS Code using snap.

And I have the latest stable release of VS Code (according to snap):

snap info code

 $ snap info code
name:      code
summary:   Code editing. Redefined.
publisher: Visual Studio Code (vscode✓)
store-url: https://snapcraft.io/code
contact:   https://twitter.com/code
license:   unset
description: |
  Visual Studio Code is a new choice of tool that combines the
  simplicity of a code editor with what developers need for the core
  edit-build-debug cycle.
commands:
  - code
  - code.url-handler
snap-id:      Ht0aUHi7ofh9Fbwh6m7jUN2pAy6kzBiu
tracking:     latest/stable
refresh-date: 33 days ago, at 21:48 -03
channels:
  latest/stable:    899d46d8 2021-12-16 (85) 228MB classic
  latest/candidate: ↑
  latest/beta:      ↑
  latest/edge:      ↑
installed:          899d46d8            (85) 228MB classic

Also, it seems like you actually are using the Remote Container. But, please perform this simple test:

Create a terminal on your VS Code and ask for the content of the CROSS_TOOLCHAIN environment variable.

Outside of the Remote Container you should see it empty (if you see some value for this variable, it is possible that you defined it somewhere for your shell):

Inside of the Remote Container you must see it not empty:

Best regards,

[billi1234]

Oh no sorry. Im on Windows and dosnt have a VM.
Our VSCode is on the same Version.

I will get inside the remote Conatiner “aarch64-linux-gnu-”

[billi1234]

or do I make some fundamental errors?

[henrique.tx]

Hi @billi1234 !

I would like to ask you for some tests:

• Try to call the toolchain from the same terminal:

${CROSS_COMPILE}gcc --version
${CROSS_COMPILE}g++ --version

• Share the content of the $PATH environment variable

• Also, share the full output log of CMake:
  

  

• And the full output log of Torizon:
  

Best regards,

[billi1234]

Hi @henrique.tx

now i have meanwhile gone back to the makefile. Without Cmake. but the above error persists nonetheless.

2. $PATH
   

   

3. Torizon OUTPUT Log
   

   

THANKS!

[henrique.tx]

Hi @billi1234 !

A side comment: to show the content of an environment variable on terminal, you need to:

echo $PATH

And, in the end, are you actually able to build something?

@kevin.tx helped me with some tests (he has the same setup as you) and even though he is also getting the same warning regarding the toolchain not being found, Kevin is able to build a hello world.

So, if you can build, there is no actual issue, but I will inform the Development Team about this warning.

[billi1234]

Hi @billi1234

yes that was a bit stupid of me. Also do not know what I was thinking at the moment.

torizon@docker-desktop:/workspaces/Backend_Makefile$ echo $PATH
/vscode/vscode-server/bin/linux-x64/899d46d82c4c95423fb7e10e68eba52050e30ba3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Ya, i can build hello world too.

Ok thanks !!