building on RPi4 and buster gets compiler errors; but completes! about libpredict HOT 3 OPEN

Update: On Arm (i.e. RPi) the -Wno-psabi flag passed to the compiler suppresses this note. I've found a few repositories that comment on this issue [1]. This is noted in the GCC release notes [2] because of a bug [3]. The following in CMakeLists.txt could be used ... but a simple ARM test to check this is way-too-broad/incorrect. However, if you trigger this, the code compiles without the note.

#ifdef(ARM)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-psabi")
set(CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -Wno-psabi")
#endif()

There's also some good posts about using #pragma vs this compile flags [4].

#pragma GCC diagnostic ignored "-Wpsabi"

This is a bit more fine grained; but like all of this; it's highly dependent on the GCC version (and the architecture being used, i.e. Arm).

Plus ... it does not work on the specific setup I have (contrary to the online manuals).

So only 1/2 a solution really.

[1] nlohmann/json#658 & https://redmine.named-data.net/issues/5106 & others
[2] https://gcc.gnu.org/gcc-7/changes.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
[4] https://forum.juce.com/t/lots-of-warnings-like-parameter-passing-for-argument-of-type-changed-in-gcc-7-1-when-compiling-with-gcc-8/33885

from libpredict.

The notes are not harmful, but annoying. Disabling -Wpsabi is not ideal, but in this case the problem is with the ABIs of libraries libpredict is linking with, and AFAICT it's not affecting libpredict's own ABI. My idea would be something like this:

if(ARM)
  check_if_cxx_source_compiles("test case to provoke the notes" HAS_GCC_BUG77738_FIX)
  set(CMAKE_REQUIRED_FLAGS "-Wno-psabi")
  check_if_cxx_source_compiles("same test case" HAS_GCC_BUG77738_FIX_WORKAROUND)
endif()

And then for relevant targets:

if (HAS_GCC_BUG77738_FIX AND HAS_GCC_BUG77738_FIX_WORKAROUND)
  set(CMAKE_C_FLAGS, "${CMAKE_C_FLAGS} -Wno-psabi")
  set(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} -Wno-psabi")
endif()

We can use the test case for GCC bug 77738, or maybe 80149 is better.

from libpredict.

s/check_if_cxx_source_compiles/check_cxx_source_compiles/g ?

The issue that 80149 [1] points out is that you don't know if the user of the library is using the same gcc in addition to the issue with underlying libraries that libpredict uses. Argggg!

This prompts me to ask ... could the vector code be written in a different way in order to avoid this warming and hence know that this won't be a compiler issue independent of compiler version?

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80149

from libpredict.