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

[Jonathan Gray]

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.

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.

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).