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.

[Sigurd Hellesvik]

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

[Mathi]

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.

[liteyear]

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.

[V.Lorz]

Now I'm also facing this same issue. The trigger for this was to include a "add_subdirectory(drivers)" in the project's CMakeLists.txt file.

Only workaround I found works for me (partly) when making fresh builds is to comment out the line in CMakeLists, the compiler/tools then generate the offset.h file, then uncomment the line and compile again.

Is there any working solution not involving doing things like these?

BR

[robertp]

Our current solution is to just run the build a few times until it works. It usually requires 3-4 attempts.

[V.Lorz]

Five or even more attempts were not enough for my case, so I had to fallback to comment/uncomment the ad_subdirectory() lines in CMakeLists.txt.

BR

[Sigurd Hellesvik]

In which file do you have add_subdirectory?

If you have a look at https://github.com/nrfconnect/ncs-example-application, you can see that add_subdirectory is used in the "top directory" and the driver/ directory, but not in the app/ directory.

Maybe you have add_subdirectory in your app/ directory while you should instead use the same structure as the example application?

[liteyear]

In my case, the add_directory is in the CMakeLists at the top level, which calls up add_directory in a drivers folder, and so on down the tree. The core source files themselves are included in the same top level CMakeLists using target_sources instead.

I'm not sure the example is a useful structure in this case - it's specifically designed to demonstrate modules (which is what the top level CMakeLists is for), and requires the developer to specify the app directory explicitly when building the app. The app itself doesn't actually use add_directory as far as I can tell.

[V.Lorz]

I think I solved both of my issues with a simple solution, and not having to refactor for using the structure demonstrated in the ncs-example-application, by simply adding following line in my root makefile:

list(APPEND EXTRA_ZEPHYR_MODULES

  ${CMAKE_CURRENT_SOURCE_DIR}/custom_mp2731_driver

)

I previously had add_subdirectory() in that makefile.

BR

[liteyear]

Does this work V.Lorz even if your driver is not a module, as such? If so, maybe that method should always be used instead of add_directory, for code with its own CMakeLists.txt that targets Zephyr?

[V.Lorz]

This works for me, but my driver does follow now (to my besto knowledge) the structure of a module.

I have `custom_mp2731_driver\dts\bindings\drivers\custom,mp2731.yaml`, which defines the component.

Then, under `custom_mp2731_driver\zephyr` I placed the driver's code (.c/.h), Kconfig, module.yml and a CMakeLists.txt file which basically contains:

  zephyr_include_directories(.)

  zephyr_library()
  zephyr_library_sources(
    custom_mp2731_driver.c
    )

I think I need to adapt the CMakeLists.txt for introducing conditional inclusion/compilation in case the module is not enabled in the project file, but it became now TODO.