Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake policy CMP0072 #360

Closed
chapulina opened this issue Jul 7, 2021 · 6 comments
Closed

CMake policy CMP0072 #360

chapulina opened this issue Jul 7, 2021 · 6 comments
Labels
bug Something isn't working

Comments

@chapulina
Copy link
Contributor

Environment

  • OS Version: Ubuntu Focal
  • Source or binary build? Source
  • CMake 3.16

Description

  • Expected behavior: Builds with no warnings
  • Actual behavior:
CMake Warning (dev) at /usr/share/cmake-3.16/Modules/FindOpenGL.cmake:275 (message):
  Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
  available.  Run "cmake --help-policy CMP0072" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.
                                                                      
  FindOpenGL found both a legacy GL library:    

    OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so

  and GLVND libraries for OpenGL and GLX:

    OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so
    OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so

  OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for 
  compatibility with CMake 3.10 and below the legacy GL library will be used.
Call Stack (most recent call first):
  /home/chapulina/dev_focal/ws_fortress/install/share/cmake/ignition-cmake2/cmake2/IgnUtils.cmake:189 (find_package)
  CMakeLists.txt:58 (ign_find_package)

Steps to reproduce

Compile from source with a CMake version higher than 3.10

Solution

If we want to keep compatibility with CMake 3.10, I think we should explicitly set the policy to OLD.

@chapulina chapulina added the bug Something isn't working label Jul 7, 2021
@mjcarroll
Copy link
Contributor

Further reference: https://cmake.org/cmake/help/git-stage/policy/CMP0072.html

I think the better behavior is to check if the policy exists and make use of the newer version. This shouldn't have any impact on our current cmake mechanisms, as far as I can tell:

if (POLICY CMP0072)
  cmake_policy (SET CMP0072 NEW)
endif(POLICY CMP0072)

I believe we also need to propagate it out to the ignition-renderingXX-ogre-config and ignition-renderingXX-ogre2-config to make sure that downstream users don't also get the warning.

@chapulina chapulina added the good first issue Good for newcomers label Jul 9, 2021
@darksylinc
Copy link
Contributor

darksylinc commented Jul 20, 2021

A bit more background on what this error mean (to make a better informed decision):

The context is switchable graphics. Eons ago drivers would replace libGL.so with their own and call it a day.

But today it is very normal to have multiple GPUs installed (specially laptops with switchable graphics between Intel and NVIDIA; AMD + Intel combo isn't a problem because they are both provided by Mesa so it's the same libGL.so)

So a new library was made, libOpenGL.so, which decides at launch time which libGL.so to launch. This interface is known as GLVND.

If configured properly launching:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo
__GLX_VENDOR_LIBRARY_NAME=mesa glxinfo

will give you different output (assuming you have NVIDIA + Intel or AMD using Mesa)

Today it works out of the box if using the NVIDIA installer (no need to mess with xorg.conf), but Ubuntu 20.04's packaged NVIDIA drivers broke this (maybe on purpose?) as trying to use mesa will give X11 interface errors.

So basically the error is saying link against libOpenGL instead of libGL to better support switchable graphics.

Ogre 2.1+ uses dlopen( "libGL.so.1", RTLD_LAZY | RTLD_LOCAL) + glXGetProcAddressARB at runtime rather than relying on the linker and it seems GLVND at that time can already intercept the call and choosing Mesa vs NVIDIA it seems to work (I use it all the time on gazebo to test NV and AMD discrete GPUs)

Ogre 1.x uses a very similar way to load OpenGL so it should be working, but I didn't check it.

Hence this CMake warning probably can be safely ignored because we don't actually link against libGL or libOpenGL during build time; unless you have other tools (other than Ogre) linking against GL directly.

@chapulina
Copy link
Contributor Author

I tried a few things here but I wasn't able to silence the warning while still using ign_find_package(OpenGL...). The cmake_policy command has complicated scoping. These didn't work:

  if (POLICY CMP0072)
    cmake_policy (SET CMP0072 NEW)
  endif(POLICY CMP0072)
  ign_find_package(OpenGL
    REQUIRED_BY ogre ogre2
    PKGCONFIG gl)
  if (POLICY CMP0072)
    cmake_policy (SET CMP0072 NEW)
  endif(POLICY CMP0072)
  ign_find_package(OpenGL
    REQUIRED_BY ogre ogre2
    PKGCONFIG gl
    EXTRA_ARGS NO_POLICY_SCOPE)
  if(POLICY CMP0072)
    cmake_policy(PUSH)
    cmake_policy(SET CMP0072 NEW)
  endif()
  ign_find_package(OpenGL
    REQUIRED_BY ogre ogre2
    PKGCONFIG gl)
  if(POLICY CMP0072)
    cmake_policy(POP)
  endif()

This does work, but we lose the REQUIRED_BY and PKGCONFIG:

  if (POLICY CMP0072)
    cmake_policy (SET CMP0072 NEW)
  endif(POLICY CMP0072)
  find_package(OpenGL)

Other things that I thought of trying:

  • Adding a POLICY parameter to ign_find_package
  • Hardcoding the policy in ign-cmake's ign_find_package
  • Creating a custom FindOpenGL.cmake where the policy is set

Does anyone have a better idea? Now that Jenkins CI is using Focal (gazebo-tooling/release-tools#565) this warning is turning the build yellow.

@darksylinc
Copy link
Contributor

What about setting OpenGL_GL_PREFERENCE variable?

I guess push/pop policy doesn't make sense in this case because once FindOpenGL has executed, the effects are irreversible (variables are set with OGL libs and folders), even if the policy is popped

@chapulina
Copy link
Contributor Author

What about setting OpenGL_GL_PREFERENCE variable?

Thanks, that does it! #528

That's still not propagated to downstream projects though, not sure if ign-cmake provides a way to propagate the variable to the config files like @mjcarroll mentioned above.

@azeey
Copy link
Contributor

azeey commented May 31, 2024

Fixed by #528

@azeey azeey closed this as completed May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants