[libcamera-devel] [PATCH 2/4] meson: enable no-psabi for gcc 9+

[Laurent Pinchart]

Hi Tomi,

On Thu, Oct 08, 2020 at 01:27:30PM +0300, Tomi Valkeinen wrote:
> On 08/10/2020 12:18, Kieran Bingham wrote:
> 
> >> This sounds a bit silly. Perhaps I'm missing something. I'm not sure what is the point with these
> >> warnings if the solution is always to add -Wno-psabi, which silences all psabi changes.
> > 
> > 
> > I haven't checked/seen the recent warnings, but from my understanding
> > they say something like
> > 
> >  "If you compile the library with GCC 6, and the application with GCC 7
> > - it will break in magical ways you would not expect"
> 
> note: parameter passing for argument of type ‘std::_Rb_tree_const_iterator<std::pair<const
> libcamera::PixelFormat, libcamera::PixelFormatInfo> >’ changed in GCC 7.1
> 
> > Which could happen for instance if the library was provided by the
> > distribution, and an individual compiled an application with a different
> > tool-chain version...
> > 
> > We currently have a minimum GCC version of 7, so we don't care about
> > that, and we're happy to ignore the warnings.
> 
> But... What does libcamera's minimum gcc version affect? A library
> libcamera uses against could be compiled with earlier gcc, no?
> 
> Or if we consider the ABI from libcamera, libcamera could be compiled
> on gcc 7, and the application on gcc 6.
> 
> > If GCC one day decides to add an ABI break at gcc 10 however, that
> > statement would change to:
> > 
> >  "If you compile the library with GCC 9, and an application with GCC 10
> > - It will break in magical ways you would not expect"
> > 
> > and that would be more problematic for us.
> > 
> > So we're happy to defer the warnings for now, but we can't ignore any
> > future additions.
> 
> But how do we separate the two different ABI breakages? There's just
> -Wno-psabi. If I understand what you say correctly, we'd like to see
> the new warning, but not the old one.

That's the idea, but it doesn't seem to be possible.

> And... So what's the fix? Rewrite all the code affected by the ABI
> change in some other way, so that you don't hit the ABI change? Is
> that even realistic? Isn't the only real fix just requiring the people
> to compile libraries and apps with gcc versions that are ABI
> compatible?
> 
> I don't think I get this whole thing =). But I'm fine with increasing
> the version check to < 10, as I'm currently using gcc 9. I'll probably
> switch my buildroot to gcc 10 at some point in the near future, and
> then I can send a new patch.

The idea is that I'd like to keep an eye on ABI breakages introduced by
gcc, in a "just for my information" fashion for the moment. I don't know
at this point how such breakages would even be handled (if at all).

"Just for my information" is probably not a good enough excuse to annoy
everybody with warnings when using new compiler versions though. I'd
thus agree to drop the version check. I wonder how the gcc developers
had envisioned this being used though, if there's a warning (which is
actually not even a warning, but a note), I imagine it was put there
with a target audience in mind. Or maybe this is just a mess and nobody
should really pay attention :-)

-- 
Regards,

Laurent Pinchart