@ya-isakov @tomeuv @ebassi

PTAL. Also, if you have a repro with one of the known downstream failures caused by #229, it would help to have someone test one of those cases.

ping.

@batesj Checked it on my libGL-free system - it works:

openat(AT_FDCWD, "/usr/lib64/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 16
....
openat(AT_FDCWD, "/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libOpenGL.so.0", O_RDONLY|O_CLOEXEC) = 21
openat(AT_FDCWD, "/lib64/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

(spam about libGLX.so is caused by lack of check, which I had in one of my other patches)
Without your patch, vanilla libepoxy:

openat(AT_FDCWD, "/usr/lib64/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 16
openat(AT_FDCWD, "/usr/lib64/libOpenGL.so.0", O_RDONLY|O_CLOEXEC) = 21
....
openat(AT_FDCWD, "/usr/lib64/haswell/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "Couldn't open libGL.so.1: libGL."..., 96Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory

But previous one worked for me, too, so, somebody with Xorg should also check...

I've tested this extensively now in Chrome OS and confirmed that it works to enable the use of libOpenGL.so while not changing behavior of existing libGLX expectations. For example, confirmed that this libepoxy change does not break crostini apps when libopengl0 is installed.

@ebassi ptal

Let's see if the people having issues in #252 and #240 can test this: @Ernest1338 and @evelikov

As an aside: there's no point in pinging me. I receive all bug mail for libepoxy.

LGTM from code inspection, we didn't experience any known crashes on FreeBSD that I am aware of but just switched to libglvnd everywhere so would like to drop the direct GLX dependency.

From a quick look libGL -> libOpenGL fallback sounds like the right thing to do. Thank you.

I would suggest a couple of things:

• elaborate/reference the inline "existing behaviour" comment - either add concrete details how, or simply reference the issues/broken workloads Draw calls missing in apitrace (regression) #240 and Upgrading libepoxy from 1.5.5 to 1.5.7 results in Xorg crashing on boot #252
• adding an in-tree test, with trivial reproducer of said bugs - so it is even harder to accidentally break in the future

Doubt I can test it at the moment @linkmauve - do you have some time to check this on your end?

Does the test need to be in this pull request or can it be a followup? The nature of this change is at the level of attempting to open libGL.so.1 and libOpenGL.so.0 so a test could have have dummy libraries that confirm libGL.so.1 is loaded if it exists, and then fall back on libOpenGL.so.0.

I'm on vacation at the moment, I will test this when I get home.

Does the test need to be in this pull request or can it be a followup? The nature of this change is at the level of attempting to open libGL.so.1 and libOpenGL.so.0 so a test could have have dummy libraries that confirm libGL.so.1 is loaded if it exists, and then fall back on libOpenGL.so.0.

I don't have a preference if tests come here or as follow-up.

The test you outlined doesn't sound super useful. Tests which do functional testing, similar to the bugs #240 #252 and even #253 would be much more valuable. Mind you I did not trace each use-case, so it might be that they all follow the exact same problematic pattern.

Note: the tests are a suggestion, ultimately it's not my call to make.

Perhaps there's an easy github workflow that would repro some of the original integration bugs in #240, #252 and/or #253. There is some investigation to be done for that, so would prefer to not block this CL -- filed #258 for that.

In the mean time this CL fixes the bug that @ya-isakov described in #229 (comment). To reiterate the motivation here: without this fix, it is impossible for a wayland-only system to use OpenGL via libepoxy.

From the outside it seems like this is an acceptable workaround to an issue that is not very well understood. With my cursory inspection it seems to require non-trivial knowledge of how these handles are used everywhere (which might affect library-consumers?) and whether there are known or unknown limitations with libOpenGL in a GLX setup. Until the issue is better understood, it is difficult to prescribe a test plan, and the salient change is to preserve old known good behavior for GLX.

This is probably obvious to most but I'll just write it here for completeness: libGL == libOpenGL + libGLX.

• elaborate/reference the inline "existing behaviour" comment - either add concrete details how, or simply reference the issues/broken workloads Draw calls missing in apitrace (regression) #240 and Upgrading libepoxy from 1.5.5 to 1.5.7 results in Xorg crashing on boot #252

Done.

@batesj I'm aware how annoying libGL.so can be. In case it's unclear - I'm not suggesting we should block this MR. I did said "suggestion" and not "requirement" exactly for that reason ;-)

Thanks for the review, @evelikov!

So I tested this, and found no issues (related to Xorg at least). ;)

Thanks for testing @Ernest1338, sounds like we can land this then.

I agree. Thanks to everyone who tested this, it's very much appreciated.

Thanks @batesj for working on this, as well.

Thanks @ebassi, let me know when you think we can release version 1.5.9 with this change.