cancel
Showing results for 
Search instead for 
Did you mean: 

clangd assumes compiler target is 'x86_64-pc-windows-msvc' for .cpp files

jostlowe
Associate III

Hi!

I have set up a project for the STM32H523RET6 using the following setup:

CubeMX: 6.15.0

STM32 vscode extension: 3.5.1

The project is configured to use starm-clang and starm-clang++ and the STARM_PICOLIBC toolchain

I have created a .cpp file () that i added to my build and updated my CMakeLists.txt with the following:

 

# Setup compiler settings
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS ON)

...

enable_language(C CXX ASM)

...

# Add sources to executable
target_sources(${CMAKE_PROJECT_NAME} PRIVATE
    Core/Src/myclass.cpp
    # Add user sources here
)

 

When building the project, it compiles fine, but clangd reports the following problem:

 

nsupported option '-mcpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfloat-abi=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)

 

Is this a known issue?

For reference (or anyone having a similar issue) i managed to temporarily fix the issue by explicitly setting the target for clangd by changing the .clangd file from

 

CompileFlags:
  Add:
    - '-ferror-limit=0'
    - '-Wno-implicit-int'
  CompilationDatabase: build/Debug
Diagnostics:
  Suppress:
    - unused-includes
    - unknown_typename
    - unknown_typename_suggest
    - typename_requires_specqual

to

CompileFlags:
  Add:
    - '-ferror-limit=0'
    - '-Wno-implicit-int'
    - '-target'
    - 'thumbv8m.main-st-none-eabihf'
    - '-mfpu=fpv4-sp-d16'
    - '-fno-exceptions'
    - '-fno-rtti'
  CompilationDatabase: build/Debug
Diagnostics:
  Suppress:
    - unused-includes
    - unknown_typename
    - unknown_typename_suggest
    - typename_requires_specqual

 

11 REPLIES 11
FluxPower42
Associate III

Hi @vincent_grenet 

thanks for the update.
I can confirm that the --query-driver entry starm-clang++.exe is no longer removed.


Unfortunately, however, I am (still) experiencing the following issue:
The clangd is NOT using the correct paths for the system includes.

I use here the NUCLEO-H753ZI board with STARM_NEWLIB setting. The following paths should be the right:

  • C files:
    c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include

  • C++ files:
    c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include\c++\v1

But if I hover the mouse over the plain C #include “pwd.h”, I see this path:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\pwd.h

FluxPower42_0-1755723829811.png

Similarly, the path is incorrect when I hovering over the C++ #include <vector>:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\c++\v1\vector

FluxPower42_1-1755723854015.png

To be absolutely sure that this is NOT the correct path, I can open these headers by clicking the blue Follow link and insert an #error “Test” at the beginning of the file. After this I perform a >CMake: Clean Rebuild , but the build is still error-free. This means: this file is not used for the build but clangd is using this. If I insert now the same #error line into the vector header file in the correct path, the build aborts as expected.

To test this easily, the attached ZIP file contains a very simple project with an application.cpp file.

 

The following changes/additions have been made:


./nucleo-h753zi-simple.ioc (via STM32CubeMx)
- NUCLEO-H753ZI board file error corrected: LD2 pin changed from PB7 to PE1 (ST: please correct the NUCLEO-H753ZI board file).
- Toolchain/IDE = CMake
- Default compiler/linker = Starm-Clang

 

./Application
- application.cpp added
- application.hpp added

 

./Core/Src/main.c
- #include “application.hpp” added to line 24.
- Call appMain(); added to line 95.

./cmake/starm-clang.cmake

- Line 28 set to: set(STARM_TOOLCHAIN_CONFIG “STARM_NEWLIB”)

 

./CMakeLists.txt
- File application.cpp added to target_sources.
- Directory Application added to target_include_directories.

 

To use this, you have to generate the files with the STM32CubeMX and open the folder with VSCode (with installed STM32Cube for VSCode extension).


Additional:
It is not clear to me why clangd does not use the correct path.
If I add --log=verbose and "stm32cube-ide-clangd.trace”: “clangd_trace.json” to settings.json,  it is possible to check what information clangd gets.
If I search for "vector" string I get lines with the correct path (in a "message" node):

FluxPower42_2-1755724439200.png

but also with the wrong path:

FluxPower42_3-1755724532146.png


@vincent_grenet 
Can you explain me this behaivior and how can I fix this?


@FluxPower42, thanks for confirming that the first fix is okay with you.

The second issue has been reproduced and confirmed.

For now, I’m able to solve the issue by hacking the .clangd file.

vincent_grenet_0-1756416629306.png
vincent_grenet_1-1756416677841.png

This may help in the short term while we work on a more solid fix. Please confirm.

I will update you once it’s fully resolved.