• State Verified Answer
  • Replies 40 replies
  • Subscribers 70 subscribers
  • Views 2380 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 318297
Options

offsets.h No such file or directory

Mathi

Hi, 

We have been using SDK version 2.1.1 and currently are in the process of migrating to SDK version 2.5.0.

Would be helpful to get some hint regarding what conditions can lead to the following error when building our application.

In file included from C:\ncs\v2.5.0\zephyr\include\zephyr\app_memory\app_memdomain.h:9,
from C:\ncs\v2.5.0\zephyr\include\zephyr\rtio\rtio.h:31,
from C:\ncs\v2.5.0\zephyr\include\zephyr\drivers\i2c.h:28,
from <our application.h>...
C:\ncs\v2.5.0\zephyr\include\zephyr\linker\linker-defs.h:26:10: fatal error: offsets.h: No such file or directory
26 | #include <offsets.h>
| ^~~~~~~~~~~

Thanks,

Mathi.

Parents
  • 0

    Hi,

    Can you explain the steps you did to update to v2.5.0? Both for the SDK and the application.

    Maybe most common is to forget to delete the build folder between versions.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd,

    Iam building an application that contains the child image mcuboot and hci_rpmsg.conf.
    I use vscode to install the new version of the SDK and toolchain.
    I can also confirm that the build error is seen only when upgrading from 2.4.2 to 2.5.0. i.e. 
    In order to re-create the problem we tried to incrementally upgrade from 2.1.1 to 2.5.0..
    i.e.
    Upgrade from 2.1.1 to 2.3.0 ==> No build error related to offsets.h generation.
    Upgrade from 2.3.0 to 2.4.0 ==> No build error related to offsets.h generation.
    Upgrade from 2.4.0 to 2.4.1 ==> No build error related to offsets.h generation.
    Upgrade from 2.4.1 to 2.4.2 ==> No build error related to offsets.h generation.
    Upgrade from 2.4.2 to 2.5.0 ==> Build fails due to offsets.h generation.

    Note: I always made sure to delete the build folder between versions.
    Please let me know if you need further information.

    Thanks,

    Mathi.

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd

    I managed to solve the problem in my build. Here is what I found out:

    The header file of our i2c abstraction included:

    #include <zephyr/drivers/i2c.h>

    This file ends up (through sub includes) to including "Offsets.h"

    If I instead move the inclusion of  <zephyr/drivers/i2c.h> to my related .cpp file - the the build is successful.
    It seems like the .h file preprocessing is done before Offsets.h is generated..
  • 0 in reply to TBing

    Hi Tonny,

    Great find. Thanks for the help. 
    I can repeat your fix. i.e. move the inclusion of the above header file into a .cpp file and it worked for me.

    Kind Regards,

    Mathi.

  • 0 in reply to TBing

    Hi Tonny,

    Great find. Thanks for the help. 
    I can repeat your fix. i.e. move the inclusion of the above header file into a .cpp file and it worked for me.

    Kind Regards,

    Mathi.

  • 0 in reply to Mathi

    Surprisingly the ticket got closed when i clicked on "Verify Answer" and now iam unable to view all the discussions.
    For the benefit of other users - iam just pasting below the solution found by Tonny Bing (TBing)

    "

    Hi Sigurd

    I managed to solve the problem in my build. Here is what I found out:

    The header file of our i2c abstraction included:

    #include <zephyr/drivers/i2c.h>

    This file ends up (through sub includes) to including "Offsets.h"

    If I instead move the inclusion of  <zephyr/drivers/i2c.h> to my related .cpp file - the the build is successful.
    It seems like the .h file preprocessing is done before Offsets.h is generated..


    "

  • 0 in reply to Mathi

    This fix didn't work for me. i2c.h was already being included from a .c file (not a .cpp file, if that matters) according to the compiler error. It was also being included from a different header file, so I stripped that out just in case, but it made no difference.

    This issue has come and gone for a long time for us. It came back recently and there's a common smoking gun with reports in this thread:

    The issue appears when I `add_subdirectory()` the file containing the offending #include, and goes away if I add it to `target_sources(app PRIVATE...` instead.

    Specifically, the .c file that includes i2c.h is in a folder with a CMakeLists.txt file that adds it to a library if a CONFIG is defined. If I include the .c file in the list that gets passed to `target_sources()` in the project's base level CMakeLists.txt file, I don't get the offsets.h issue. But I also can't control inclusion using prj.conf. If instead I add the folder with `add_subdirectory()` in the project's base level CMakeLists.txt file I get the normal CMake features like CONFIG control, but the offsets issue appears.


Reply
  • 0 in reply to Mathi

    This fix didn't work for me. i2c.h was already being included from a .c file (not a .cpp file, if that matters) according to the compiler error. It was also being included from a different header file, so I stripped that out just in case, but it made no difference.

    This issue has come and gone for a long time for us. It came back recently and there's a common smoking gun with reports in this thread:

    The issue appears when I `add_subdirectory()` the file containing the offending #include, and goes away if I add it to `target_sources(app PRIVATE...` instead.

    Specifically, the .c file that includes i2c.h is in a folder with a CMakeLists.txt file that adds it to a library if a CONFIG is defined. If I include the .c file in the list that gets passed to `target_sources()` in the project's base level CMakeLists.txt file, I don't get the offsets.h issue. But I also can't control inclusion using prj.conf. If instead I add the folder with `add_subdirectory()` in the project's base level CMakeLists.txt file I get the normal CMake features like CONFIG control, but the offsets issue appears.


Children
No Data
Related