This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Cmake 3.19 breaks Zephyr RTOS - Getting: Assertion Failed: The toolchain is unable to build a dummy C file. in Segger Embedded Studio nRF-Nordic

Hi,

I have filed an issue over at cmake regarding this issue:

https://gitlab.kitware.com/cmake/cmake/-/issues/21512

As someone else has already posted on stack overflow:

https://stackoverflow.com/questions/64985685/assertion-failed-the-toolchain-is-unable-to-build-a-dummy-c-file

I've been experiencing the same issue with SES after by brew updated Cmake to 3.19-branch ... having rolled it back to 3.17.2 ... everything work again as it did before (I'm on macOS 10.15). I am also right now using/testing 3.18.4 ... and it too seems to work ...

Maybe nRF + Zephyr + Segger + Cmake can have a joint look into this issue?

Cheers,

Daniel.

  • Hi, Seludeft!

    Thank you for reaching out. We're aware that there are certain issues regarding the nRF Connect SDK and the corresponding tools, especially on MacOS. However, I do believe I can purpose a fix in your case. Could you try the following:

    1. Close SES
    2.
    Run the following command in your terminal: rm -r ~/Library/Caches/zephyr
    3. Reopen SES and chose the "Clean build folder" option when opening a new project

    What I believe is happening here is that the "zephyr" cache contains old Toolchain information that doesn't correspond to your updated CMake version. Hence, deleting the cache should solve the problem. 
    Please report back if this is successful or not. 

    Best regards,
    Carl Richard

  • Hi Carl, 

    Thanks for the tips ... I did try them (read older post here...) when I was debugging the issue ... though, sadly this doesn't work.

    Also, in the stack overflow (https://stackoverflow.com/questions/64985685/assertion-failed-the-toolchain-is-unable-to-build-a-dummy-c-file) post ... the author is experiencing the exakt same issue (with Cmake 3.19-branch) on his Windows platform ... 

    So, I don't think this is a macOS-only issue ... 

    When I was reading the stack overflow post, he writes he's been in contact with the Zephyr-folk (via Slack) ... and noticed this issue being more wide spread ...

    And the Zephyr-folks recommended rolling back Cmake to 3.17.2 ... which I've done ... and everything works again.

    Daniel.



    PS - I was also curious, and have switched to Cmake 3.18.4 (the last brew'd package in HomeBrewed, before the switch to 3.19-branch releases) ... and I can confirm that 3.18.4 is also working.

    PPS - In my debugging this issue, I tried all of the released of SES 4.20a --> 5.20b (macOS) ... so it's not a SES issue, they all have the exact same issue with Cmake 3.19-branch

    PPPS - You also only see this issue when you're "Clean build" in the "Open nRF Project"-dialog window (or rm -rf build-dir in command line) ... and assume the rm -r ~/Library/Caches/zephyr does the same thing... in short when we "start fresh" with a new build-dir that hasn't a pre-compiled cache of the "test builds" ... and it looks like Cmake 3.19-branch doesn't execute / function properly ... I have read the new code in 3.19 ... and they've done a lot of changes ... so I'm guessing there is a tiny "bug" hidden in all of their latest and greatest features :) 

  • Hi again!

    Thanks for the thorough summary and testing of the issue! I agree that this definitely must be related to some other problem (likely with CMake) and will do as you suggested: try to involve Nordic, Zephyr and CMake on solving it!

    Good to hear that the previous versions are working at least. I guess the best solution currently is to stay on one of those.

    Have a good weekend and cheers,
    Carl Richard

  • Hi!

    Short update already! There is a workaround currently being tested. Have a look at the pull request.

    Best regards,
    Carl Richard

  • Thanks, have a good one you too 

    PS - for everyone on macOS ... follow the following instructions on how to "roll back" HomeBrew ... pin the older versions of CMake 3.18.4 / 3.17.2 ... and then "roll forward" again ... 

    gist.github.com/.../1b8d0c11338dc9ab79b2386309828894

    This way we can wait until a solution is present :-) 

    Also - make sure that in the "roll back" that you brew unlink cmake ninja ... brew reinstall cmake ninja ... brew pin cmake ninja ... before "rolling forward" again .... keeping cmake + ninja in sync or you'll get other issues with it complaining that they "don't match" (one of the lessons learned during my debugging ...) 

Related