Rebuild for Python 3.7, GCC 7, R 3.5.1, openBLAS 0.3.2

[xhochy]

Fixes #17

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xhochy]

Updated to the latest mesa release and seeing what CI says.

[doutriaux1]

@xhochy thanks for this!

[xhochy]

We probably need to switch to meson as a build system; that's what all other distributions have done.

[doutriaux1]

@xhochy I'm not familiar with meson do you have a link please?

[doutriaux1]

got it: https://mesonbuild.com/ I will look into it if i get time. But feel free to go ahead 😉

[henryiii]

Is the only failure an invalid certificate chain on the Travis worker? Would rerunning that worker fix the problem? Edit: Nevermind, the other worker built and had a problem.

[croth1]

Could it be that the OSX error is due to clock_gettime not being defined before sdk 10.12, but CF is using 10.9? See e.g. https://github.com/zeromq/libzmq/issues/2175

[croth1]

Should we skip macOS here and try to fix it later?

[croth1]

@conda-forge/core @conda-forge/mesalib, any idea how to continue here?

[isuruf]

My suggestion is to build 17.3.9 as in master and worry about the new version later

[doutriaux1]

it doesn't look like it is picking up the -std=c11 flag

../include/c11/threads_posix.h:391:9: error: implicit declaration of function 'clock_gettime' is invalid in C99 [-Werror,-Wimplicit-function-declaration]

According to: https://clang.llvm.org/compatibility.html it might be worth using the following on OSX:

Compile in the GNU C89 dialect by adding -std=gnu89 to the set of Clang options. This option is only recommended if the program source cannot be changed or if the program also relies on additional C89-specific behavior that cannot be changed.

[jakirkham]

It looks like it is picking up the -std=c11 flag fine as it appears to have found the C11 headers. 😕

IIUC macOS doesn't define clock_gettime (and some other things here). Please see this old blog post. So the error being raised is mesalib tried using clock_gettime on macOS, but it isn't defined on macOS. So the build failed with some complaints about missing definitions.

Sounds like a bug in their detection code during the build. Maybe they have a patch upstream or in one of the other macOS package distributions? Alternatively we can roll our own.

FWIW this is what they have done historically for macOS, which works fine. That said IDK how well it applies to their thread use case.

[jakirkham]

Should we add a version branch in case there are people still wanting the latest version as well?

[croth1]

It seems like this is currently stale due to time constraints of the contributors. At some point in the commit history we had a version that built for linux, but not for macOS.

Is it an option to go back to this commit, and unblock by skipping the macOS build for now? If I am not mistaken, the macOS sdk has the headers/libraries for mesa anyway, so we could build against native headers instead (correct me if I am wrong!)

[hmaarrfk]

18 fixes the builds for Linux. DOn't know about OSX. PR submitted to xhonchy's https://github.com/xhochy/mesalib-feedstock/pull/1

All I can see is: https://trac.macports.org/ticket/54638 , but there isn't a clear patch to use. And http://mac-os-forge.2317878.n4.nabble.com/mesa-17-1-6-build-failed-on-Snow-Leopard-td341884.html

[hmaarrfk]

Basically this patch makes it impossible to use mesalib with OSX https://gitlab.freedesktop.org/mesa/mesa/commit/af09b867329bcc5d50c22c2e634f5c5deb51e184

Tag 17.1 introduces the use of LRU cache eviction https://gitlab.freedesktop.org/mesa/mesa/blob/17.1/src/util/disk_cache.c

Therefore, the last build possible for OSX is 17.0 https://gitlab.freedesktop.org/mesa/mesa/blob/17.0/src/util/disk_cache.c

[hmaarrfk]

The immediate children are:

• freecad: doesn't use mesalib for OSX
• gmsh: doesn't use mesalib for OSX
• libva: only builds for linux
• paraview: only builds on linux, but due to time constraints, so unclear if OSX is desirable
• root5: actually uses mesalib for OSX. But maybe it can fallback on the prebuilt one that we used before? Or maybe it doesn't need it, depends on the results of this PR https://github.com/conda-forge/root5-feedstock/pull/8

[jakirkham]

Disabling macOS builds of mesalib seems reasonable to me.

[hmaarrfk]

Hi All,

it seems that OSX 10.9 just isn't a supported platform for modern versions of mesa-lib. I was able to compile a 17.0 for OSX and 17.3 for linux in #20.

I had to disable the legacy compilers. All CIs now pass.

I think #20 should be merged in to keep the compiler upgrade going forward.

CC: @jakirkham, @conda-forge/mesalib

Mark

[hmaarrfk]

Nice work @xhochy

I managed to catch @mariusvniekerk at a good time to ask him to merge this!!!