[Mesa-dev] [PATCH 1/5] mesa: bump required GCC version to 4.8.0

[Emil Velikov]

Hi all,

On 7 September 2016 at 16:54, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Wed, Sep 07, 2016 at 11:52:39PM +1000, Timothy Arceri wrote:
>> On Wed, 2016-09-07 at 19:26 +1000, Jonathan Gray wrote:
>> > LLVM was imported yes, but the integration of it has only
>> > started around the same time and it is not enabled by default yet.
>> > And it was only imported around two days or so ago.
>> >
>>
>> Which means its a good time to start a discussion on what the inclusion means
>> for Mesa :)
>>
>> > And LLVM does not support all the architectures OpenBSD builds Mesa
>> > on.
>> >
>> > Can you point to something specific that needs a newer GCC version?
>> > Do you want to target c++11 or the like?
>>
>> We have discussed specific features in the past. At this point its move about
>> giving developers the freedom to use any new features they wish. And
>> ultimately the ability to bump the required version again in future.
>>
>> It seems you are talking about the possibly of never switching to clang for
>> building Mesa and sticking with gcc 4.2 for years to come. There is also the
>> issue as I understand it that your gcc 4.2 is not really gcc 4.2, as you say
>> features have been back ported to support Mesa so its possible that Mesa would
>> not even build for a normal gcc 4.2 build and our build requirements act more
>> as a restriction on developers using features rather than enforcing a building
>> requirement.??
>
> You seem to have misinterpreted.  The current plan is to switch
> some architectures to clang in the future.
>
> If your patch gets committed to Mesa I'll have to either revert it locally
> or stop updating Mesa in the short term.  Ideally configure would be a bit more
> intelligent and test functionality rather than a version number.
>
Fwiw I agree with this.

Sadly not many of us a) know which functionality is already covered
(and which isn't) in the minimum required version and/or b) have the
time to write the tests. So doing a version check is the next best
thing.

I'm not sure how others would feel, but I won't object if we have
patch(es) that add such tests. An alternative would be to have
different version to compare against for OpenBSD's gcc, which isn't
perfect but its short and simple.

> I don't have a full list of changes made to acommodate Mesa,
> here are some found with a quick search,  I believe FreeBSD has
> also adopted many of these.
>
> - binary integer constants (gnu extension clang also has)
> http://marc.info/?l=openbsd-cvs&m=137290441510098&w=2
> - support for \<word\> in regcomp (sysv/gnu extension)
> http://marc.info/?l=openbsd-cvs&m=141019114911164&w=2
>
> - named initialisers for anonymous structs/unions (required by C11)
> http://marc.info/?l=openbsd-cvs&m=146244074408249&w=2
>
> alpha ICE fix with __sync builtins
> http://marc.info/?l=openbsd-cvs&m=145663405924066&w=2
> i386 fix __sync_val_compare_and_swap_8() for -fPIC
> http://marc.info/?l=openbsd-cvs&m=144898317222499&w=2
>
> The sync builtins are assumed to be present on architectures where
> they are not available at the instruction level.  GCC was modified
> to additionally provide/expand these on at least mips64 and alpha.
>
> mips bfd -Bsymbolic fix
> http://marc.info/?l=openbsd-cvs&m=144856828610069&w=2
>
> enum attribute handling fix
> http://marc.info/?l=openbsd-cvs&m=144421363218215&w=2
>
> recognise 'F'/'f' suffix for indent (cat is now used if gnu indent not found)
> http://marc.info/?l=openbsd-cvs&m=142190494629047&w=2
>
>
>> It is my feeling that we should be bumping the gcc requirements for Mesa based
>> on the actual gcc project. Freezing the limit at the version of a forked gcc
>> variant, and using features from higher versions that have been back ported to
>> that fork seems backwards to me.
>>
>> To me the current situation seems??untenable, besides the issues with having a
>> minimum version that won't actually build Mesa I don't believe we should be
>> forced to worry about ancient compilers indefinitely??due to the decisions??of a
>> singe distro. In my opinion we should bump the version and let OpenBSD resolve
>> any issues however it sees fit (patch gcc/mesa, freeze mesa, etc). Others may
>> feel differently.
>
> There are already various local patches required to build Mesa, many pending
> review.  Another could be added.
>
Which reminds me to double-check for any outstanding patches of yours ;-)

> Subportions of the Mesa tree such as those that aren't built by visual studio
> or recently merged projects such as the intel vulkan support already
> assume the compiler is a new version of gcc in my experience.  It seems
> anonymous structs/unions turned up everywhere when redhat declared the rhel
> version which didn't have them eol for example.
>
> Where as the vulkan code seems to directly depend on linux syscalls for
> at least futexes and memfd (checks for which should be added to configure
> as well, currently the build errors out).
I'd toggle those off and tackle as time permits. Then again, if
there's interest in Vulkan it would be better to start with the loader
;-)

Regards,
Emil