CMake project not recognizing header files in sysroot/usr/local/include

Sysprogs forums Forums VisualGDB CMake project not recognizing header files in sysroot/usr/local/include

This topic contains 9 replies, has 2 voices, and was last updated by  support 1 week ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #26074


    I have been using VisualGDB for a bit to cross-compile a project for a Raspberry Pi. I’ve synchronized the sysroot from the Raspberry Pi successfully, and I know the header files are present in the local sysroot, but I can’t get Visual Studio to compile, it just reports Error snap7.h: No such file or directory for whatever header it is unable to find.

    Interestingly, the Clang autocomplete works fine with those headers, it just appears that the build is not properly including the usr/local/include folder in the sysroot. It also compiles correctly if I copy the header files from usr/local/include to /usr/include, but I don’t intend on doing that on the remote system and I feel like this should be configurable without having to manually adjust the sysroot.

    Where should I be looking in my configuration to resolve this? I’m using a CMake project that I imported from an already existing CMake project that I had manually created on Visual Studio 2017 Professional with VisualGDB Custom 5.4R12.

    • This topic was modified 2 weeks ago by  nOlander.



    Please ensure you are using the Advanced CMake Project Subsystem. Then you will be able to use the automatic header discovery to fix the project settings automatically.

    If you prefer to configure everything by hand, you would need to find the target (i.e. an library or an executable) that contains the faulty source file and add the directory containing the source file to its include directories under VS properties for that target.

    If you still cannot find the corresponding settings, please let us know your project type (Advanced CMake/Regular CMake) and we will provide more detailed instructions.



    I’m fairly certain I have it configured as an Advanced CMake project, but how would I tell?

    I’ve tried to use the automatic header discovery and I’ll get the notification about “Found one additional include directory required by the current file”, which edits the appropriate CMake file, but it only seems to resolve the autocomplete/red squiggles error and I still get the compilation error.

    If possible, I would prefer to leave the CMake files untouched as much as possible because I know they work with the directory structure on the Linux system, but I will make changes if needed. When you say “VS properties for that target”, what do you mean? I’ve selected the specific .a item in the solution explorer and added the sysroot/usr/local/include directory to the include directories list, but it hasn’t made a change in the build.


    You must be logged in to view attached files.


    Sorry, it’s hard to suggest anything specific without knowing more details (how exactly is the target declared, what is the current directory with the header file and exactly is is spelled in the Makefile, what exactly gets edited in the CMakeLists.txt file).

    One possible cause for this would be CMakeLists.txt using the regular /path/on/target syntax to specify include directories instead of ${CMAKE_SYSROOT}/path/on/target. The former syntax will only work when compiling directly, while the latter will work both when building on Linux and Windows.

    VS properties for the target can be opened by right-clicking on the target (specific executable or library) in Solution Explorer and selecting “Properties”.

    Edit: the VisualGDB 5.5 development branch does automatically use the ${CMAKE_SYSROOT} syntax for automatically discovered directories (e.g. VisualGDB-, however it hasn’t fully passed all our internal tests and may be less reliable than the stable v5.4 release.

    • This reply was modified 1 week, 6 days ago by  support.


    This is how the CMake file is set up:

    The directory with the header file that’s not being found is  C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/local/include and it gets added to the CMakeLists.txt via this line: target_include_directories(Snap7-Wrapper PRIVATE ../../=/usr/local/include). I did notice that it was being inserted above the already existing target_include_directories for that target, so I tried manually editing it in to the existing one but it didn’t make a difference.

    You mentioned making sure to utilize ${CMAKE_SYSROOT}/path/to/include format, but I noticed that the line inserted automatically didn’t do that and instead used ../../=/usr/local/include.

    Do those help at all?

    I also checked the VS Properties for the project and under Type it says “CMake Project”. Is this a regular CMake Project like you said and if so, how can I change it to and Advanced CMake Project?



    Thanks, this indeed helps understand what is going on.

    Indeed, the ../../=/usr/local/include syntax is incorrect (the correct one should be ${CMAKE_SYSROOT}/usr/local/include). The development branch of VisualGDB 5.5 should already use the correct syntax, but if you don’t want to upgrade before v5.5 reaches the stable release stage, simply try replacing C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot with ${CMAKE_SYSROOT} and the project should build both on Linux and Windows.



    I made that change in my CMake file, but it’s still reporting No such file or directory even after changing the CMakeLists.txt and clean/rebuild the entire solution. Is there any way to view the output of CMake generating the make command? I can only find the output for the build, not including CMake.



    Strange. Please try enabling verbose build (add “-v” to Ninja command-line arguments or “VERBOSE=1” to GNU Make command line arguments via VisualGDB Project Properties -> CMake Proejct Settings -> Ninja/Make command) and then build the project again.

    It will show the exact command lines used by the build system for each file. Please locate the command line for any file from that library and check what is going on (e.g. ${CMAKE_SYSROOT} got expanded incorrectly, or the path is not present in the command line at all).

    If you are not sure, please post the corresponding command line from the build log and your updated target_include_directories() statement and we will help you understand it.

    P.S. You can also try using our CMake Debugger to quickly understand what is going on. It allows stepping through CMake statements and will evaluate variables like ${CMAKE_SYSROOT}.



    When I output the value of ${CMAKE_SYSROOT} it is printing the correct path to the sysroot but I’m still getting that same error when I build. This seems to be the affected due to you

    which outputs


    My make output is the following:

    Does this help you in resolving the issue all?

    • This reply was modified 1 week ago by  nOlander.


    Sorry, it looks like you did not add “VERBOSE=1” to the GNU Make command-line arguments (see our previous reply), hence Make did not dump the gcc command lines.

    Please try adding it as suggested and share the updated log that should include the exact gcc command lines used to build the code.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.