google-deepmind
Cannot find GL/gl.h when building from source
Hi,
Following this issue I'm trying to build mujoco from source, hoping that it will solve my rendering problems.
I have the following libraries installed on the machine:
- libglfw3
- libglew2.0
- libgl1-mesa-glx
- libosmesa6
Here's my workflow:
git clone https://github.com/deepmind/mujoco
cd mujoco
mkdir build
conda install -c conda-forge gcc -y
conda install -c conda-forge ninja -y
cmake .. -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_PREFIX:STRING=$HOME/.mujoco -DMUJOCO_BUILD_EXAMPLES:BOOL=OFF -DGLFW_USE_OSMESA=1 -DCMAKE_C_COMPILER:STRING=gcc -DCMAKE_CXX_COMPILER:STRING=g++ -G Ninja
cmake --build . --config=Release
When calling cmake --build I get the following failure on multiple occasions:
FAILED: simulate/CMakeFiles/simulate.dir/uitools.c.o
/data/home/vmoens/cluster/conda/envs/mbrl_mujocosource/bin/gcc -DEIGEN_MPL2_ONLY -DMJSIMULATE_STATIC -DmjUSEPLATFORMSIMD -I/data/home/vmoens/cluster/work/mujoco/simulate -I/data/home/vmoens/cluster/work/mujoco/build/_deps/glfw-src/include -I/data/home/vmoens/cluster/work/mujoco/build/_deps/lodepng-src -I/data/home/vmoens/cluster/work/mujoco/include -O3 -DNDEBUG -fPIE -fvisibility=hidden -fdata-sections -ffunction-sections -mavx -Wno-int-in-bool-context -Wno-maybe-uninitialized -Wno-sign-compare -Wno-str
ingop-overflow -Wno-stringop-truncation -pthread -std=c11 -MD -MT simulate/CMakeFiles/simulate.dir/uitools.c.o -MF simulate/CMakeFiles/simulate.dir/uitools.c.o.d -o simulate/CMakeFiles/simulate.dir/uitools.c.o -c /data/home/vmoens/cluster/work/mujoco/sim
ulate/uitools.c
In file included from /data/home/vmoens/cluster/work/mujoco/simulate/uitools.h:18, from /data/home/vmoens/cluster/work/mujoco/simulate/uitools.c:15:
/data/home/vmoens/cluster/work/mujoco/build/_deps/glfw-src/include/GLFW/glfw3.h:241:12: fatal error: GL/gl.h: No such file or directory
241 | #include <GL/gl.h>
| ^~~~~~~~~ compilation terminated.
Any help would be appreciated
On Ubuntu, try installing: libosmesa6-dev libxrandr-dev libxinerama-dev libxcursor-dev libegl1-mesa-dev
Note that if you are using compilers from conda-forge, you may have unexpected behaviour in using them with the libraries or tools provided by apt, because you could be mixing different ABI-incompatible versions of the same library or the conda-forge compiler can have different default locations for looking for includes or libraries.
If you want to compile mujoco with apt dependencies, there is any reason why you can't use the gcc installed by apt?
If instead you want to use conda to install the dependencies of mujoco, you probably need to install the mesa-libgl-devel-cos7-x86_64 package (see https://conda-forge.org/docs/maintainer/knowledge_base.html#libgl and https://github.com/conda-forge/cdt-builds) to find the GL/gl.h header.
Thanks @traversaro
The main reason why I was using gcc from conda is that I assumed that I needed a newer version than the one installed with apt (7) since the .github workflow uses version >10. I still have the same issue with the native gcc and the libs mentioned above installed with apt.
The reason why i'm using conda is that i have a limited access to sudo on the clusters i'm working on, and I must rely on other engineers in another time zone to install packages for me (which they're a bit reluctant to do as they will be exposed to the whole team).
@nimrod-gileadi I have tried to install them with conda, but it did not work. Again, apt may succeed where conda fails but it's harder for me to install with apt.
@traversaro On the other hand, as soon as you start interacting with X11 and GLX you're most likely already interacting with stuff outside of conda-forge anyway, no?
@vmoens I'd just try and see if anything goes wrong with older GCC. Just because we only run GCC down to version 9 on GH Actions doesn't mean that things won't work with older versions.
Also, my hunch is that https://github.com/deepmind/dm_control/issues/310 won't be resolved by building MuJoCo from source, especially since you said that it can render a few frames fine at the start.
The header lookup issue isn't going to go away by changing the compiler version, no. I was responding to your comment The main reason why I was using gcc from conda is that I assumed that I needed a newer version than the one installed with apt.
@traversaro On the other hand, as soon as you start interacting with X11 and GLX you're most likely already interacting with stuff outside of conda-forge anyway, no?
Kind of. Some X11 libraries are packaged as regular libraries in conda-forge, while regarding libGL.so the system one is tipically used at runtime, while at build time a CDT package (https://conda-forge.org/docs/maintainer/knowledge_base.html#core-dependency-tree-packages-cdts) is typically used. The tricky part here is that the conda-forge C preprocessor (differently from the system one) has been built to not look by default in /usr/include or /usr/local/include. See for example the default include directories (printed via gcc -xc -E -v -) for a gcc compiler just installed in a conda-forge env:
(gcc) straversaro@IITICUBLAP257:~$ mamba list
# packages in environment at /home/straversaro/mambaforge/envs/gcc:
#
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
binutils_impl_linux-64 2.36.1 h193b22a_2 conda-forge
gcc 12.1.0 h9ea6d83_10 conda-forge
gcc_impl_linux-64 12.1.0 hea43390_16 conda-forge
kernel-headers_linux-64 2.6.32 he073ed8_15 conda-forge
ld_impl_linux-64 2.36.1 hea4e1c9_2 conda-forge
libgcc-devel_linux-64 12.1.0 h1ec3361_16 conda-forge
libgcc-ng 12.1.0 h8d9b700_16 conda-forge
libgomp 12.1.0 h8d9b700_16 conda-forge
libsanitizer 12.1.0 ha89aaad_16 conda-forge
libstdcxx-ng 12.1.0 ha89aaad_16 conda-forge
sysroot_linux-64 2.12 he073ed8_15 conda-forge
(gcc) straversaro@IITICUBLAP257:~$ gcc -xc -E -v -
Reading specs from /home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/x86_64-conda-linux-gnu/12.1.0/specs
could not find specs file conda.specs
COLLECT_GCC=gcc
Target: x86_64-conda-linux-gnu
Configured with: ../configure --prefix=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho --with-slibdir=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib --libdir=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib --mandir=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/man --build=x86_64-conda-linux-gnu --host=x86_64-conda-linux-gnu --target=x86_64-conda-linux-gnu --enable-default-pie --enable-languages=c,c++,fortran,objc,obj-c++ --enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp --enable-libquadmath --enable-libquadmath-support --enable-libsanitizer --enable-lto --enable-threads=posix --enable-target-optspace --enable-plugin --enable-gold --disable-nls --disable-bootstrap --disable-multilib --enable-long-long --with-sysroot=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/x86_64-conda-linux-gnu/sysroot --with-build-sysroot=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_build_env/x86_64-conda-linux-gnu/sysroot --with-gxx-include-dir=/home/conda/feedstock_root/build_artifacts/gcc_compilers_1652324151713/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/x86_64-conda-linux-gnu/include/c++/12.1.0 --with-pkgversion='conda-forge gcc 12.1.0-16' --with-bugurl=https://github.com/conda-forge/ctng-compilers-feedstock/issues/new/choose
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (conda-forge gcc 12.1.0-16)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
/home/straversaro/mambaforge/envs/gcc/bin/../libexec/gcc/x86_64-conda-linux-gnu/12.1.0/cc1 -E -quiet -v -iprefix /home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/x86_64-conda-linux-gnu/12.1.0/ -isysroot /home/straversaro/mambaforge/envs/gcc/bin/../x86_64-conda-linux-gnu/sysroot - -mtune=generic -march=x86-64 -dumpbase -
ignoring nonexistent directory "/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/x86_64-conda-linux-gnu/12.1.0/../../../../x86_64-conda-linux-gnu/include"
ignoring duplicate directory "/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-conda-linux-gnu/12.1.0/include"
ignoring nonexistent directory "/home/straversaro/mambaforge/envs/gcc/bin/../x86_64-conda-linux-gnu/sysroot/usr/local/include"
ignoring duplicate directory "/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-conda-linux-gnu/12.1.0/include-fixed"
ignoring nonexistent directory "/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-conda-linux-gnu/12.1.0/../../../../x86_64-conda-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/x86_64-conda-linux-gnu/12.1.0/include
/home/straversaro/mambaforge/envs/gcc/bin/../lib/gcc/x86_64-conda-linux-gnu/12.1.0/include-fixed
/home/straversaro/mambaforge/envs/gcc/bin/../x86_64-conda-linux-gnu/sysroot/usr/include
End of search list.
So you can't use it as a drop in replacement for the system compiler, unless you manually specify /usr/include and /usr/local/include directories in the compiler invocation. That is also the reason CDT packages are necessary to use GL/gl.h.
