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

[Kieran Bingham]

Hi Laurent,

On 16/07/2020 15:37, Laurent Pinchart wrote:
> Hi Kieran,
> 
> 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.



>> 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
--
Kieran