Bug 236592 – [CMake] Cannot find OpenGL when system provides opengl.pc instead of gl.pc

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Adrian Perez]

In some systems the OpenGL library cannot be found if the pkg-config module
is called “opengl” (and henceforth values picked from “opengl.pc”) instead
of plainly “gl” (with values from “gl.pc”).

One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd)
is used as main GL library, letting it dispatch to the most suitable OpenGL
implementation at runtime depending on the system state. In this case the
main library would be libOpenGL.so.0 instead of libGL.so.1 and/or libGLX.so.0;
then libOpenGL.so.0 will handle dispatching lib(EGL|GLX)_<vendor>.so.<N> (for
example libEGL_mesa.so.0 for non-X11 operation with free software Mesa drivers,
or libGLX_nvidia.so.0 when running under X with the proprietary Nvidia driver).

Some notes:

 - If opengl.pc is found, the library name will be libOpenGL.so.0, and it
   will *not* contain GLX symbols. In that case we need to search for glx.pc
   as well, which may include additional flags/libraries that one needs to
   link in order to get the GLX symbols.

 - If gl.pc is found, it can either be provided by libglvnd or not; and in
   both cases linking to the library specified in the pkg-config module *will*
   result in being able to find the GLX symbols.

Therefore:

 - If opengl.pc is *not* found (no libglvnd), we want to keep our existing
   logic: try gl.pc first, fall back to checking the “gl” and “GL” library
   names, and try to figure out whether GLX headers can be found.

 - If opengl.pc is found (libglvnd present), we should prefer that as
   the GL library to link against, and we need to check for the existence of
   glx.pc to determine whether GLX_FOUND should be set.

 - If opengl.pc is found but glx.pc is *not* found we might want to fallback
   to the checking for the gl.pc and the GLX headers as stated above.

Thanks for Haelwenn “lanodan” Monnier who pointed out on IRC that Gentoo has
been carrying a patch to change the checked pkg-config module and library
names to use libglvnd, which allows them to successfully build WebKitGTK :]

[Adrian Perez]

While at it, maybe it would be a good idea to try and convert
the FindOpenGL.cmake file to use imported targets \o/

[Haelwenn (lanodan) Monnier]

Created attachment 451902 [details]
Patch against WebKitGTK 2.34.3 for X11-less OpenGL

Hi,

Actually the patch in question isn't pushed anywhere, including Gentoo, specially because it doesn't works as-is when opengl.pc isn't present, it should always be there on Gentoo's side of things but better be safe than sorry.

Adding it as attachment, could try to make it correctly fallback to gl.pc, likely with inspirations from CMake's findOpenGL module (which works quite well).
It also includes changes for OpenGLShims.h

[Michael Catanzaro]

(In reply to Adrian Perez from comment #0)
> One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd)
> is used as main GL library, letting it dispatch to the most suitable OpenGL
> implementation at runtime depending on the system state.

Not so on Fedora, this is easy to disprove:

$ pkg-config --cflags --libs opengl
-lOpenGL 
$ pkg-config --cflags --libs gl
-lGL 

$ rpm -qf /usr/lib64/pkgconfig/gl.pc
libglvnd-devel-1.3.4-2.fc35.x86_64
$ rpm -qf /usr/lib64/pkgconfig/opengl.pc
libglvnd-devel-1.3.4-2.fc35.x86_6

$ rpm -qf /usr/lib64/libOpenGL.so.0.0.0 
libglvnd-opengl-1.3.4-2.fc35.x86_64
$ rpm -qf /usr/lib64/libGL.so.1.7.0 
libglvnd-glx-1.3.4-2.fc35.x86_64

All of the above are provided by glvnd.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #3)
> (In reply to Adrian Perez from comment #0)
> > One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd)
> > is used as main GL library, letting it dispatch to the most suitable OpenGL
> > implementation at runtime depending on the system state.
> 
> Not so on Fedora, this is easy to disprove:
> 
> $ pkg-config --cflags --libs opengl
> -lOpenGL 
> $ pkg-config --cflags --libs gl
> -lGL 
> 
> $ rpm -qf /usr/lib64/pkgconfig/gl.pc
> libglvnd-devel-1.3.4-2.fc35.x86_64
> $ rpm -qf /usr/lib64/pkgconfig/opengl.pc
> libglvnd-devel-1.3.4-2.fc35.x86_6
> 
> $ rpm -qf /usr/lib64/libOpenGL.so.0.0.0 
> libglvnd-opengl-1.3.4-2.fc35.x86_64
> $ rpm -qf /usr/lib64/libGL.so.1.7.0 
> libglvnd-glx-1.3.4-2.fc35.x86_64
> 
> All of the above are provided by glvnd.

On Arch Linux we have the same as for Fedora, but that's not the case
in every system where libglvnd is used. At any rate, even if libglvnd
*usually* provides libGL.so.1 for backwards-compat, linking against it
is considered a legacy practice because programs that use EGL will end
up linked against X11 libraries unneedlessly, which is the reason for
preferring using -lOpenGL/opengl.pc and then iff a program purposedfully
uses GLX, adding -lGLX/glx.pc.

[Adrian Perez]

While at it, I am revamping our FindOpenGL.cmake module to define
imported targets so it will define OpenGL::OpenGL and OpenGL::GLX,
which is more robust and will allow simplifying other places of
the build system that make use of variables defined by the module.

[Adrian Perez]

Created attachment 452176 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE

[Adrian Perez]

Created attachment 452185 [details]
Patch v2

This should make the WPE build green.

[Michael Catanzaro]

Dude... would you even still need this FindOpenGL.cmake if you switched to epoxy? It looks like you're going far out of your way to avoid a big simplification of the code.

Still good to land, though, since it fixes a build failure and is better than we have now. I was going to give r=me, but Don beat me to it.

[Don Olmstead]

(In reply to Michael Catanzaro from comment #9)
> Dude... would you even still need this FindOpenGL.cmake if you switched to
> epoxy? It looks like you're going far out of your way to avoid a big
> simplification of the code.
> 
> Still good to land, though, since it fixes a build failure and is better
> than we have now. I was going to give r=me, but Don beat me to it.

I would like to see the libepoxy requirement go away and its either you do a system OpenGL ES 2/3 or ANGLE.

[Michael Catanzaro]

(In reply to Don Olmstead from comment #10)
> I would like to see the libepoxy requirement go away and its either you do a
> system OpenGL ES 2/3 or ANGLE.

We don't currently require libepoxy, but are planning to.

I don't know why you'd like to see it go, because it would eliminate all of this complexity (e.g. OpenGLShims.h, etc.)

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #11) 
> We don't currently require libepoxy, but are planning to.

I suppose we could limit this to WPE/GTK only.

[Don Olmstead]

(In reply to Michael Catanzaro from comment #12)
> (In reply to Michael Catanzaro from comment #11) 
> > We don't currently require libepoxy, but are planning to.
> 
> I suppose we could limit this to WPE/GTK only.

My understanding is you all want to enable WebGL 2 and that requires ANGLE and ANGLE would thus handle all of the things libepoxy is handling for you. That's why I would assume you all would get rid of it in the future.

[Michael Catanzaro]

Hm, I dunno. We have bug #235626 for that.

[EWS]

Committed r289949 (247351@main): <https://commits.webkit.org/247351@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 452185 [details].

[Radar WebKit Bug Importer]

<rdar://problem/89045498>

[Zan Dobersek]

Breaks WPE builds with -DUSE_ANGLE_WEBGL=ON:

> CMake Error at Source/ThirdParty/ANGLE/CMakeLists.txt:150 (add_library):
>   Target "GLESv2" links to target "OpenGL::GLES" but the target was not
>   found.  Perhaps a find_package() call is missing for an IMPORTED target, or
>   an ALIAS target is missing?
> 
> 
> CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library):
>   Target "WebCore" links to target "OpenGL::GLES" but the target was not
>   found.  Perhaps a find_package() call is missing for an IMPORTED target, or
>   an ALIAS target is missing?
> Call Stack (most recent call first):
>   Source/WebCore/CMakeLists.txt:2106 (WEBKIT_FRAMEWORK_DECLARE)
> 
> 
> CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library):
>   Target "WebCoreTestSupport" links to target "OpenGL::GLES" but the target
>   was not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> Call Stack (most recent call first):
>   Source/WebCore/CMakeLists.txt:2107 (WEBKIT_FRAMEWORK_DECLARE)
> 
> 
> CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library):
>   Target "WebKit" links to target "OpenGL::GLES" but the target was not
>   found.  Perhaps a find_package() call is missing for an IMPORTED target, or
>   an ALIAS target is missing?
> Call Stack (most recent call first):
>   Source/WebKit/CMakeLists.txt:450 (WEBKIT_FRAMEWORK_DECLARE)
> 
> 
> CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library):
>   Target "TestRunnerShared" links to target "OpenGL::GLES" but the target was
>   not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> Call Stack (most recent call first):
>   Tools/TestRunnerShared/CMakeLists.txt:1 (WEBKIT_FRAMEWORK_DECLARE)
> 
> 
> CMake Error at Source/cmake/WebKitMacros.cmake:129 (add_executable):
>   Target "WebKitTestRunner" links to target "OpenGL::GLES" but the target was
>   not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> Call Stack (most recent call first):
>   Tools/WebKitTestRunner/CMakeLists.txt:136 (WEBKIT_EXECUTABLE_DECLARE)
> 
> (repeated for I guess every other target)

[WebKit Commit Bot]

Re-opened since this is blocked by bug 236757

[Adrian Perez]

(In reply to WebKit Commit Bot from comment #18)
> Re-opened since this is blocked by bug 236757

Gah, I did try a GTK build with -DUSE_ANGLE_WEBGL=ON and -DENABLE_WEBGL2=ON,
which succeeded, but not a WPE build. I'll give it try and make sure WPE also
builds fine before updating the patch again.

[Adrian Perez]

Created attachment 452507 [details]
Patch v3


This fixes the build issues when using USE_ANGLE_WEBGL=ON for the WPE port,
which caused the revert of the previous version of the patch. I have tested
that both the GTK and WPE ports can be built successfully with the options
USE_ANGLE_WEBGL and ENABLE_WEBGL2 enabled.

[EWS]

Committed r290138 (247479@main): <https://commits.webkit.org/247479@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 452507 [details].