[libcamera-devel] GCC v5,v6 Support and beyond C++14

[Laurent Pinchart]

Hi Kieran,

On Mon, Jul 27, 2020 at 11:36:29AM +0100, Kieran Bingham wrote:
> On 16/07/2020 15:37, Laurent Pinchart wrote:
> > On Thu, Jul 16, 2020 at 03:12:26PM +0100, Kieran Bingham wrote:
> >> There has been a few issues lately where we have discussed the minimum
> >> requirements for libcamera, and we have been supporting from GCC v5
> >> onwards as much as we can.
> >>
> >> We already depend on features and functionality which is provided in a
> >> v5.0+ kernel, so that is currently a limiting factor on the low end of
> >> support.
> >>
> >> If we no longer support GCC v5 and 6, I believe we would also have no
> >> reason not to move up beyond C++14 to C++17.
> >>
> >> To do so, we need to check that we really don't need to support gcc v5
> >> or gcc v6 though:
> >>
> >> - Ubuntu only brought in kernel v5.0 at 18.04.3,
> >>   and 18.04 ships with gcc v7.
> > 
> > Is it as easy to install a custom (backported ?) toolchain on Ubuntu
> > 16.04 (or on other distributions for that matter) that it would be to
> > install a custom kernel ? Of course "easy" is a subjective concept,
> > building a kernel is certainly easy for me :-)
> 
> I decreed building custom kernels for your own distro to be not easy
> while I was trying to run VIMC on my laptop:
> 
>   https://twitter.com/kieranbingham/status/1145973350025576448?s=20
> 
> Mostly, I think because I hit issues with Secure-boot, but anyway.
> 
> You can install any toolchain you build of course, but I can't see
> someone deciding that their best course of action to using libcamera is
> to manually build and install the oldest GCC/clang they can and use it
> just for libcamera ...
> 
> Ubuntu does let you easily have parallel of multiple gcc/clang versions
> from the official packages though, and they are simply in the $PATH with
> their versions.
> 
> (which I'm using for my build-matrix).
> 
> > Let's also note that, while we require at least a v5.0 kernel, we will
> > in practice depend on newer kernels for some pipeline handlers. I'm
> > thinking about vimc in particular, I'm not sure we'll keep support for
> > older versions once the scaler gets fixed on the kernel side for
> > instance. I would also not be surprised if we end up depending on fixes
> > to the IPU3 ImgU driver that are not yet in mainline (because they
> > haven't been developed yet :-)).
> > 
> >> - On Debian,
> >>    Stretch(9) uses kernel v4.14,
> > 
> > And ships gcc 6.3.0.
> > 
> >>    Buster(10) has kernel v5.4, and ships with GCC v8.
> >>
> >> - Fedora picks up a v5.0 kernel in Fedora 30, which ships gcc v9.
> > 
> > Should we consider OpenSUSE too ? Gentoo and Arch are certainly not an
> > issue, and neither are Chrome OS or Android. How about professional
> > distributions such as RHEL, do we need to care about them ?
> 
> I haven't used OpenSuse much I'm afraid so I don't know.
> 
> RHEL5 supported in longterm, runs a 2.6 kernel ... Uhh lets skip forwards.
> 
> Ok, so even RHEL8 runs a 4.18 kernel.
> 
> Lets leave it up to Red hat to support libcamera on that if they desire it.

Agreed.

I have no objection against dropping support for gcc 5 and 6.

> >> So I don't foresee much reason to keep gcc 5/6 support around ...
> >> Does anyone know of a distribution that provides a kernel >= 5.0 which
> >> ships gcc <= 6?
> > 
> > How about buildroot- or yocto-based systems ?
> 
> As they 'build their own' toolchains, (they can use prebuilts too) and
> are entirely focused around supporting the build environment, I can't
> see any 'need' to require an old toolchain there...
> 
> Or put more clearly, If someone 'needs' C++17 to build libcamera, it
> would be entirely feasible for them to meet that need.
> 
> > I was hoping kernel v5.0+ would require a newer gcc version, but it
> > seems it still supports gcc 4.9. No luck there.

-- 
Regards,

Laurent Pinchart