Closed jfrancis71 closed 10 months ago
My reading of the documentation around Core Dependency Tree packages seems to suggest that the intention is for the conda compiler to fall back on the system wide files for this, but this does not seem to be happening. I am not sure I have fully understood this part, so I may be have misunderstood and any assistance would be appreciated.
I see the confusion here. Basically for OpenGL and similar conda-forge relies on the system version for what regards loading libraries when executing an executable or a shared library that uses it, but when compiling some C/C++ code that include those headers, it expects the cdt packages to be installed. Just for reference, the CDT libraries that we install while compiling packages that require opengl are:
So either:
mamba install -c conda-forge -c robotology-staging mesa-libgl-devel-cos7-x86_64 mesa-dri-drivers-cos7-x86_64 libselinux-cos7-x86_64 libxxf86vm-cos7-x86_64
or
mamba install -c conda-forge -c robotology-staging mesa-libgl-devel-cos7-x86_64 mesa-dri-drivers-cos7-x86_64 libselinux-cos7-x86_64 libxdamage-cos7-x86_64 libxxf86vm-cos7-x86_64 libxfixes-cos7-x86_64 libxext-cos7-x86_64 libxau-cos7-x86_64 xorg-libx11 xorg-libxext
should solve your problem.
Excellent: Your first solution worked in my system conda setup.
Additionally: I am suspicious that the cmake package management plays well with conda package management, so I setup up 2 docker images to test both of your solutions, and both of them work.
I wonder if this mamba install information belongs in the install instructions or perhaps in the FAQ? I don't think I would have discovered it by myself without your help.
I now have the ORB3 examples running in ROS 2 RoboStack environment (now to get it running connected to a live camera!)
My lego robot and I thank you for your help, we are most appreciative.
I wonder if this mamba install information belongs in the install instructions or perhaps in the FAQ? I don't think I would have discovered it by myself without your help.
Sure, would you be interested in proposing a PR against https://github.com/RoboStack/robostack.github.io/blob/master/docs/FAQ.md or somewhere in the docs? Thanks!
Hi I recently found myself in a similar problem and reading this issue help me solving it, I notice thought that the Pull request submited by @jfrancis71 was in your fork and not againts the RoboStack one.
If you agree I would be more than happy to resubmit your PR againts the RoboStack one if you prefer.
Hi I recently found myself in a similar problem and reading this issue help me solving it, I notice thought that the Pull request submited by @jfrancis71 was in your fork and not againts the RoboStack one.
If you agree I would be more than happy to resubmit your PR againts the RoboStack one if you prefer.
Yes, thanks!
Hi all, Apologies, I must have got the process slightly wrong. Please feel free to go ahead and get the pull request submitted correctly. Thanks, Julian.
Solution to issue cannot be found in the documentation.
Issue
I am attempting to build a ROS node for the ORB3 SLAM monocular camera setup but am running into difficulties.
I can compile up Pangolin/ORB3 fine using the system wide installed compiler. However I understand that if I wish to integrate with RoboStack ROS2 I need to be using the compiler from the conda environment.
The core of the problem appears to be that after running the installation local tools command as per installation instructions I have a file: /miniconda3/envs/ros2_4/include/GL/glu.h which has on line 38:
include <GL/gl.h>
These are the files in my ~/miniconda3/envs/ros2_4/include/GL/:
-rw-rw-r-- 6 julian julian 11008 Apr 2 2018 freeglut_ext.h -rw-rw-r-- 6 julian julian 681 Oct 21 2003 freeglut.h -rw-rw-r-- 6 julian julian 27097 Feb 16 2022 freeglut_std.h -rw-rw-r-- 6 julian julian 5871 Mar 26 2018 freeglut_ucall.h -rw-rw-r-- 6 julian julian 1186601 Jul 31 2017 glew.h -rw-rw-r-- 6 julian julian 17255 Mar 29 2020 glu.h -rw-rw-r-- 6 julian julian 3315 Mar 29 2020 glu_mangle.h -rw-rw-r-- 6 julian julian 639 Oct 21 2003 glut.h -rw-rw-r-- 6 julian julian 73435 Jul 31 2017 glxew.h -rw-rw-r-- 6 julian julian 63314 Jul 31 2017 wglew.h
As you can see there is no gl.h
However this is present in: /usr/include/GL/gl.h ie the system wide location. So the system wide compiler does find this file, but the conda compiler does not.
My reading of the documentation around Core Dependency Tree packages seems to suggest that the intention is for the conda compiler to fall back on the system wide files for this, but this does not seem to be happening. I am not sure I have fully understood this part, so I may be have misunderstood and any assistance would be appreciated.
Here is a simple program (test.cc) to illustrate:
and CMakeLists.txt:
error message: /home/julian/miniconda3/envs/ros2_4/include/GL/glu.h:38:10: fatal error: GL/gl.h: No such file or directory 38 | #include <GL/gl.h>
Any help much appreciated.
Installed packages
Environment info