Epoxy fails to detect the (non-epoxy) GLX context under Wayland.

[gogglesguy]

This issue has been introduced as part of the 1.5.0 release and as far as I can see this was broken with the following commit: 7c4817f2eed2faf0353c1ceb5f38b500f6aff7cf

Problem: Epoxy fails to detect the current GLX context created by a non-epoxy code.

Work environment is as follows:

1. Running GNOME under wayland ( loginctl showsession c2 -p Type => Type=wayland )
2. Running traditional X11 app using FOX Toolkit (www.fox-toolkit.org) library.
3. FOX does not use epoxy, the application does use epoxy.
4. The GLX context is created and made current by the FOX library before the application makes any epoxy based calls.

Cause:

1. GLX context set up and made current by non-epoxy library code.
2. application makes a call to _epoxy_has_glextension()
3. As part of _epoxy_internal_has_glextension(), it enters _epoxy_get_bootstrap_procaddress() (for glGetString) and opens the api.egl_handle succesfully. The call to _epoxy_egl_get_current_gl_contextapi() returns EGL_None since there's no EGL Context set up. It falls back to GLX and api.gl_handle gets loaded. However api.glx_handle is not set at this point.
4. The call to glGetStringi in _epoxy_internal_has_glextension() will execute _epoxy_current_context_isglx(). At this point: api.egl_handle is valid and api.glx_handle is null which results in the function returning false (epoxy_current_context_is_glx:580)

Probably related to #163

[nwnk]

I'm thinking the bootstrap code should maybe use dl_iterate_phdr to gently detect whether GLX or EGL is already loaded.

[gogglesguy]

I'm thinking the bootstrap code should maybe use dl_iterate_phdr to gently detect whether GLX or EGL is already loaded.

A dlopen() with RTLD_NOLOAD would do the same?

[nwnk]

Can you try this branch?

https://github.com/nwnk/libepoxy/tree/even-more-gentle-glx-detection

[gogglesguy]

@nwnk yes those changes made it work.

Before, with the most recent libepoxy 1.5.1 I was getting: gogglesmm: ../libepoxy/src/dispatch_common.c:862: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.

With your changes, the program runs fine and no longer exits.

[ebassi]

PR #168 was merged.

[baedert]

The hunk adding RTLD_NOLOAD causes epoxy to report no glx on my x11 system now. The path is epoxy_has_glx -> epoxy_conservative_glx_dlsym -> get_dlopen_handle (which passes exit_on_fail = false).

[nwnk]

Huh, yeah it would. Similarly it would break epoxy_has_egl. I suppose those have to have side effects, otherwise we're forcing the app to do all the dlopen work itself. Patches shortly...

[ebassi]

Merged #170 and @baedert confirmed it fixed the issue on IRC.

[nihguy]

I've faced the same problem on Fedora 30 when I've tried to compile this GTKmm's GLArea example.

yum info libepoxy

Installed Packages
Name         : libepoxy
Version      : 1.5.3
Release      : 2.fc30
Architecture : x86_64
Size         : 1.2 M
Source       : libepoxy-1.5.3-2.fc30.src.rpm
Repository   : @System
From repo    : anaconda
Summary      : epoxy runtime library
URL          : https://github.com/anholt/libepoxy
License      : MIT
Description  : A library for handling OpenGL function pointer management.

Available Packages
Name         : libepoxy
Version      : 1.5.3
Release      : 2.fc30
Architecture : i686
Size         : 207 k
Source       : libepoxy-1.5.3-2.fc30.src.rpm
Repository   : fedora
Summary      : epoxy runtime library
URL          : https://github.com/anholt/libepoxy
License      : MIT
Description  : A library for handling OpenGL function pointer management.

When I run the code from the repo (using Wayland) the following message is thrown:

gtkmm_glarea_test: ../src/dispatch_common.c:863: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.