building on RPi4 and buster gets compiler errors; but completes!

[mahtin]

Using the latest g++ on RPi4 ...

$ g++ --version
g++ (Raspbian 8.3.0-6+rpi1) 8.3.0
...
$

Produces 1200+ make error log file. However, it all comes down to these few errors:

 ... note: parameter passing for argument of type ‘std::move_iterator<double*>’ changed in GCC 7.1
 ... note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<double*, std::vector<double> >’ changed in GCC 7.1
 ... note: parameter passing for argument of type ‘std::vector<double>::iterator’ {aka ‘__gnu_cxx::__normal_iterator<double*, std::vector<double> >’} changed in GCC 7.1
 ... note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<const double*, std::vector<double> >’ changed in GCC 7.1

I feel this is a. deep in the code one line fix; however, with 1200+ lines of make error log file; it could be easier for someone else to see this issue.

The cmake output is:

$ cmake ..
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test HAS_LINKER_VERSION_SCRIPT
-- Performing Test HAS_LINKER_VERSION_SCRIPT - Success
-- Performing Test HAS_LINKER_EXPORTED_SYMBOLS_LIST
-- Performing Test HAS_LINKER_EXPORTED_SYMBOLS_LIST - Failed
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/martin/src/github/la1k/libpredict/build
martin@rpi400:~/src/github/la1k/libpredict/build $ 

[mahtin]

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

[ryeng]

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.

[mahtin]

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