Compilation errors when migrating from SDK 2.1.x to 2.5.x: [-Werror=strict-prototypes], [-Werror=unused-parameter], [-Werror=ignored-qualifiers]

[smul]

Hi.

I am updating an nrf9160 B1 project on a custom board in SDK 2.1.0 to SDK 2.5.3, and I am running into a problem when building. This error does not show up when building for 2.1.0 to 2.1.3. When compiling I get a lot of errors from the different libraries, both from zephyr and nrf, here is an example for each type:

/home/user/ncs/v2.5.3/zephyr/include/zephyr/sys/cbprintf.h:302:1: error: function declaration isn't a prototype [-Werror=strict-prototypes]
  302 | typedef int (*cbprintf_cb)(/* int c, void *ctx */);
      | ^~~~~~~

/home/user/ncs/v2.5.3/zephyr/include/zephyr/net/net_mgmt.h:268:51: error: unused parameter 'timeout' [-Werror=unused-parameter]
  268 |                                       k_timeout_t timeout)
      |                                       ~~~~~~~~~~~~^~~~~~~

and

/home/user/ncs/v2.5.3/zephyr/include/zephyr/net/wifi.h:400:1: error: type qualifiers ignored on function return type [-Werror=ignored-qualifiers]
  400 | const char * const wifi_ps_wakeup_mode_txt(enum wifi_ps_wakeup_mode ps_wakeup_mode);
      | ^~~~~

These errors show up many places in different libraries in both Zephyr and nrf libriares. Both newlib and picolibc flag the same errors. It seems that there is some CMake list somewhere adding these as compile options, but it's not in any of mine. I cannot seem to find out what these stem from. Using west does not seem to yield different results.
Here are some of the options that I see added when building runs ncs/toolchains/7795df4459/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-Wall -Wextra -Werror -Wmissing-braces -Wmissing-field-initializers -Wswitch-default -Wswitch-enum
-Wimplicit-fallthrough=3 -Wpointer-arith -Wbad-function-cast -Wstrict-overflow=5 -Wformat=2 
-Wformat-security -Wformat-overflow=2 -Wshadow -Wcast-qual -Wcast-align -Wnested-externs 
-Wunreachable-code -Wlogical-op -Wfloat-equal -Wdouble-promotion -Wstrict-prototypes 
-Wmissing-prototypes -Wundef -Wuninitialized -Winit-self -Wduplicated-branches

I am using VS Code 1.90.2 on Fedora 40, with NRF SDK 2.5.3 and toolchain 2.5.3.

Here's a general idea of the changes I've made when migrating:

• Changed includes throughout my project
• Removed CONFIG_PM
• Changed AGPS to AGNSS in configs and source files
• Added CONFIG_FLASH_MAP=y and CONFIG_STREAM_FLASH=y

Note: I have redone the entire migration (done it twice) to make sure that I didn't miss anything.

What could be the issue? If you have any docs or anything at all I would greatly appreciate it.
Sincerely,
Smul.

[tesc]

Hi,

It doesn't look like we have seen something like this before. If this does not happen to SDK samples, but only to your project, then it is most likely project specific.

Can you check with the .config output file if you somehow have gotten the CONFIG_COMPILER_WARNINGS_AS_ERRORS config set?

During the migration, did you at any point change any settings related to warnings, or other compiler settings?

Regards,
Terje

[smul]

Hi Terje, thank you for the response. I have deliberately set CONFIG_COMPILER_WARNINGS_AS_ERRORS=n, and the output .config file reflects this.

I haven't changed any compiler settings during the migration, and further I've tried to change all "Max compiled-in log level for x" settings in the Kconfig GUI, but to no avail. I've also searched for the compiler options in the project files, but these aren't found anywhere meaningful (there is one, but it only affects a single file, and does nothing when deleted).

Yes, from the two samples I've tested, AWS IoT and Blinky, it seems that it is project specific. My thoughts are going toward rebuilding the application with new CMake lists, but I was hoping for a different option.

Any ideas on things to search for or try?

[Elfving]

fatal error: offsets.h: No such file or directory
   26 | #include <offsets.h>
      |          ^~~~~~~~~~~
compilation terminated.

When it comes to this issue, you might find a solution here.

Could you try building the project again with "west -vvv build ..." in order to get the building log extra verbose?

Regards,

Håkon

[smul]

I took another look at the different CMakeLists, and found out that I'd somehow missed these options being added in the drivers' respective CMakeLists, despite searching for them in VS Code earlier. Turns out it was all a simple oversight. Embarrassing!

Removing the compiler options and adding add_dependencies where needed to avoid the problem with offsets.h yields a successful build.

The question remains whether this is fine, as it compiled successfully with these options in the past, but I'll mark this as solved for the time being.

Thank you for your help, and sorry for wasting your time.