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). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
