On 29-08-18 14:40, Kenneth Hoste wrote:
On 29/08/2018 12:15, Caspar van Leeuwen wrote:
Dear all,
I've been trying to compile Blender with CUDA support. We had a
working EasyConfig in our local repo (see attached), which recently
broke. It now produces the error:
In file included from
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_ContextGLX.h:41:0,
from
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_WindowX11.cpp:51:
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/extern/glew/include/GL/glxew.h:1758:29:
error: expected initializer before
<E2><80><98>glxewInit<E2><80><99>
GLEWAPI GLenum GLEWAPIENTRY glxewInit ();
We found out the problem occured since we had recompiled our
CUDA-9.0.176 module. It now prepends the 'extras/CUPTI/include'
directory to the CPATH, since a change in the CUDA EasyBlock about a
year ago or so.
Indeed, see
https://github.com/easybuilders/easybuild-easyblocks/pull/1306 (change
was introduced in EasyBuild v3.5.1).
This path unfortunately, also includes (rather old) GL headers.
Oh goodie...
The reason is probably that those are used by CUDA to compile
its examples, but they mess up our installation process for Blender. A
manual install, where we take out this path from the CPATH, worked.
My question is: how should we solve this?
1) Don't have the CUDA module prepend extras/CUPTI/include CPATH
(upside: old GL headers are not picked up anymore. Downside, the
actual CUPTI headers for profiling are also not picked up so user
would have to include these manually).
2) Have the CUDA EasyBlock remove (just) the old GL headers from the
extras/CUPTI/include path (downside: not default CUDA installation,
examples may not build. Upside: you can leave CUPTI headers in CPATH)
3) 'hack' the Blender EasyConfig (or a Blender EasyBlock) to do a
tricky thing to get extras/CUPTI/include out of the CPATH, e.g. in the
prebuildstep or something. Upside: CUPTI headers can remain prepended
in CPATH in the CUDA module, and the CUDA examples will build 'out of
the box'. Downside: feels very dirty and other software MAY run into
the same, old GL headers.
What's your opinion? Which option is best? Or is there another, better
option?
Hmm, I'm torn between 2 & 3, I guess...
This problem hasn't popped up anywhere else, but it clearly can, it's
not at all specific to just Blender. >
So I guess option 2 is more favorable... They really shouldn't be
shipping old GL headers anyway. Are they just shipping headers, or more
(e.g. also libraries)?
Just OpenGL headers.
Paul
--
Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl |
