Repository: spack/spack

Issue:
Installation issue: paraview with osmesa and python
### Steps to reproduce the issue

```console
$ spack install paraview+osmesa+python
==> Error: An unsatisfiable version constraint has been detected for spec:

    python@2.7:2.8
        ^pkgconfig@0.9.0:


while trying to concretize the partial spec:

    mesa+osmesa
        ^expat
        ^py-mako@0.8.0:
            ^py-markupsafe@0.9.2:
                ^py-setuptools
                    ^python@2.7:2.8
                        ^pkgconfig@0.9.0:


mesa requires python version 3:, but spec asked for 2.7:2.8
```

### Platform and user environment

```commandline
$ uname -a 
Linux vc-fey.localdomain 3.10.0-957.12.1.el7.x86_64 #1 SMP Mon Apr 29 14:59:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -d
Description:    CentOS Linux release 7.6.1810 (Core)
``` 

### Additional information
This install conflict was introduced by commit 9f848205e431c



Discussion:
I'm seeing some problems due to this meson stuff as well. Also seemingly related to this, `gtkplus` seems to have needlessly been added to some things, which depends on `libepoxy` which then depends on `llvm` of all things. So if I try to install `image-magick`, it builds many unnecessary dependencies. I'm going to install Paraview today with the latest Spack, so I expect to have problems and I will report them.
One more note, I think this is due to the preferred version of Python still 2.7.16, so `spack install paraview+osmesa+python ^python@3.7.3` might fix the concretization.
In fact Paraview seems to dislike python@3.7.3 - I'm getting further with python@3.6.8 ...
Oh no, I'm currently trying to build it with python 3.7.3. I removed all the Python 2 constraints in the Paraview package to test it.
My test environment is: python@3.6.8, mesa@19.0.3 and paraview@5.5.2.  The PV build gets to ~50% and dies on target vtkProbeOpenGLVersion with a bunch of unresolved symbols that are satisfied by libGL.  I commented out that target and the build proceeds to ~80% and likewise dies.  Working on fixing up CMakeList.txt files to try to link in this (now missing?) dependency.  I'm not clear why the change to newer mesa and/or python would introduce this type of error ...
I'm using paraview@5.6.0 and I'm seeing errors with VTK and MPI4py. I noticed this seems to indicate Python 3.7.1 should be fine with paraview@5.6.0 https://www.paraview.org/Wiki/ParaView_Release_Notes#Python_3.7.1_now_supported
Yep, those errors with MPI4py were why I backed off to the latest python@3.6.x.
I decided to just try the master branch:
```
    git      = 'https://github.com/Kitware/ParaView.git'
    
    version('5.6.0', branch='master', submodules=True)
    #version('5.6.0', sha256='cb8c4d752ad9805c74b4a08f8ae6e83402c3f11e38b274dba171b99bb6ac2460')
```
Now I think I'm up to the point of getting the missing GL symbols you are seeing.

For example:
```
lib64/libvtkRenderingOpenGL2-pv5.6.so.5.6: undefined reference to `glGetDoublev'
```
I'm trying this now https://github.com/spack/spack/pull/11400
Edit: Didn't help
While python 3 should work, the unsatisfiable version issue is from python 3 being a build-only deep for mesa which spack doesn't effectively separate.  You should be able to do a two step install via:
```
spack install mesa+osmesa
spack install paraview+osmesa+python
```
That will let osmesa use python3 as a build-only deep and paraview use python2 as a build+run dep without the unsatisfiable version issue.
@opadron you were seeing a similar issue with vtk weren't you?
Working around the Python issue is fairly simple by using Paraview master, or Python 3.6, but these missing OpenGL symbols are much more difficult to track down.

I guess they are in Mesa, so like @DarylGrunau was saying I guess the linking to Mesa is broken.
@chuckatkins yeah, I was also running into missing GL symbols when building VTK with osmesa.

We've pushed changes that we are expecting to resolve those issues, although I haven't yet had the chance to retry my VTK builds.  I'll follow up on this thread once I've tried rebuilding VTK.
@jrood-nrel the mpi4py issue seems to be a problem with using VTK's vendored mpi4py.  #11432 should have fixed that.
So, I retried building VTK and I am also (still) running into link-time issues involving missing symbols.  In my case, it looks like libGL is not being linked at all.  `libGLEW` and `libOSMesa` are there (from spack's `glew` and `mesa` packages, respectively), but `libGL` from `mesa` is not there, and I believe it should be.

Caveat 1: I'm trying this with a modified `package.py` for `VTK`.  [Here](https://gist.github.com/opadron/458ebeb535d3373c17043ef12fbbef44) is the version I am currently working with.

Caveat 2: I'm trying to build with the follow spec:
```
vtk @8.0.1    %gcc @8  +osmesa ~mpi
  ^netcdf                      ~mpi
  ^mesa                +osmesa      swr=avx,avx2
  ^llvm                ~all_targets
```
Here is what I'm seeing with the old mesa that worked for me in Paraview and the new one:
```
$ ls /software/2019-05-08/spack/opt/spack/linux-centos7-x86_64/gcc-7.4.0/mesa-19.0.3-paqqmqxzhccq4tsh7goza7njk4rth5pr/lib/
libglapi.so    libglapi.so.0.0.0  libGL.so.1      libOSMesa.so    libOSMesa.so.8.0.0  libswrSKX.so.0      pkgconfig
libglapi.so.0  libGL.so           libGL.so.1.5.0  libOSMesa.so.8  libswrSKX.so        libswrSKX.so.0.0.0
$ ls /software/2019-01-10/spack/opt/spack/linux-centos7-x86_64/gcc-7.3.0/mesa-18.1.2-nnj2azqonwar5evbhzt2mlril4rin6fe/lib/
libglapi.la    libglapi.so.0.0.0  libGLESv1_CM.so.1      libGLESv2.so        libGL.la    libGL.so.1.5.0  libOSMesa.so.8
libglapi.so    libGLESv1_CM.la    libGLESv1_CM.so.1.1.0  libGLESv2.so.2      libGL.so    libOSMesa.la    libOSMesa.so.8.0.0
libglapi.so.0  libGLESv1_CM.so    libGLESv2.la           libGLESv2.so.2.0.0  libGL.so.1  libOSMesa.so    pkgconfig
```
It looks like I'm missing GLES, which probably doesn't matter, but I am missing `libGL.la` which I'm not sure if that matters if `libtool` is doing something with it.
@jrood-nrel @opadron I think I've tracked this down to a mesa issue upstream, I'll iterate and update spack as soon as possible once I work it out with the mesa maintainers.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mesa/package.py b/var/spack/repos/builtin/packages/mesa/package.py
--- a/var/spack/repos/builtin/packages/mesa/package.py
+++ b/var/spack/repos/builtin/packages/mesa/package.py
@@ -82,6 +82,10 @@ class Mesa(MesonPackage):
     # Was included in the upstream patch release for 19.0.4
     patch('glproto-mr806.patch', when='@19.0.0:19.0.3')
 
+    # Fix missing gl symbols in OSMesa
+    # https://bugs.freedesktop.org/show_bug.cgi?id=109659
+    patch('meson-expose-glapi-through-osmesa.patch', when='@19.0.0:')
+
     def meson_args(self):
         spec = self.spec
         args = [


Test patch: