Bug 93189

Mesa cannot be built with non-gcc compilers, no matter how many bugs you cc me on.

Vinson, Alan,


If Oracle itself has no interest on building Mesa with Solaris Sudio component, let's save everybody's time by making that dependency crystal clear.


That is, let's just modify configure.ac to abort if Mesa is not built with a supported compiler (ie, GCC, Clang, or MSVC).


Or maybe, instead of a whitelist, do a blacklist (ie, detect Solaris CC and abort.)  As that might be more future proof (e.g., if another GCC look-alike compiler appears in the future.)


Anybody knows a reliable way to detect Solaris CC on configure.ac?

There was interest in the past, but trying to keep up is too hard and the
benefit too small, so we've just given up and build Mesa with gcc now.

(In reply to Jose Fonseca from comment #2)
> Anybody knows a reliable way to detect Solaris CC on configure.ac?

Whoops, missed this part.   It's easy - autoconf will set $GCC to "no".
A more definitive way involves checking if the C compiler defines
__SUNPRO_C or the C++ compiler defines __SUNPRO_CC - for instance, in
the xorg-macros.m4 for autoconf, see the XORG_COMPILER_BRAND macro:

http://cgit.freedesktop.org/xorg/util/macros/tree/xorg-macros.m4.in?id=util-macros-1.19.0#n1500

(In reply to Jose Fonseca from comment #2)
> Vinson, Alan,
> 
> 
> If Oracle itself has no interest on building Mesa with Solaris Sudio
> component, let's save everybody's time by making that dependency crystal
> clear.

I would tend to agree, but I looked at the code in question:

define p_atomic_inc(v) (void) (\
   sizeof(*v) == sizeof(uint8_t)  ? atomic_inc_8 ((uint8_t  *)(v)) : \
   sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16((uint16_t *)(v)) : \
   sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32((uint32_t *)(v)) : \
   sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64((uint64_t *)(v)) : \
                                    (assert(!"should not get here"), 0))

I don't think that would build on any compiler... and it doesn't seem that hard to fix.

static inline _p_atomic_inc(void *v, size_t s)
{
    assert(s == sizeof(uint8_t) ||
           s == sizeof(uint16_t) ||
           s == sizeof(uint32_t) ||
           s == sizeof(uint64_t));

    switch (s) {
    case sizeof(uint8_t):  atomic_inc_8 ((uint8_t  *)(v)); break;
    case sizeof(uint16_t): atomic_inc_16((uint16_t *)(v)); break;
    case sizeof(uint32_t): atomic_inc_32((uint32_t *)(v)); break;
    case sizeof(uint64_t): atomic_inc_64((uint64_t *)(v)); break;
    default: unreachable("Bad size");
    }
}

#define p_atomic_inc(v) _p_atomic_inc(v, sizeof(*v))

One could probably create a macro or two to generate the other functions.

The point of the ternary magic is to make the macros typeless, like gcc's atomic ops built-ins (https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html)

The problem is that a bunch of them have to return a value and you can't do that without statement-expressions which is unsupported by MSVC.


In this particular case, the problem seems to be that we're doing the (assert(...), 0) trick on a place where the atomic doesn't have to return a value. Wouldn't it be fine to just change 0 -> (void)0?

But I think I've already spent way too long on this. Vinson, please do not file bugs about Oracle Solaris Studio compile errors. Patches are of course welcome.

It doesn't make sense to spend time on supporting platforms for which there are no active developers.

Keeping Mesa compiling across GCC and MSVC is already quite time consuming.

I posted a couple of patches to mesa-dev for review that explicitly refuse to build with Sun CC and remove special code we had for it.

So as of commit 51564f04b77e6d29a888a4fbd83d96de062ac634 we officially require GCC on Solaris.

Thanks.