libgldispatch segfault

[jascase901]

I am running audit wheel from a manylinux2014 docker image. I currently get a segfault when I try to import the lib from the installed wheel.

wheel was generated with this command.
audit wheel repair dist/redacted.whl
If I unzip the wheel I can see its linking my system gl distpatch, as well as the patchelfed one.
ldd REDACTEDCpp.cpython-38-x86_64-linux-gnu.so | grep GL

 ldd REDACTEDCpp.cpython-38-x86_64-linux-gnu.so | grep GL
    libEGL-29b68110.so.1.1.0 => /home/redacted/projects/redacted/tmp/REDACTEDCpp/./REDACTEDcpp.libs/libEGL-29b68110.so.1.1.0 (0x00007f422d7a7000)
    libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f422ccc3000)
    libGLdispatch-dcc1ca97.so.0.0.0 => /home/redacted/projects/redacted/tmp/REDACTEDCpp/./REDACTEDcpp.libs/libGLdispatch-dcc1ca97.so.0.0.0 (0x00007f42290fe000)
    libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f4228cc7000)
    libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f4228a11000)

I can also tell audit wheel to exclude libGLdispatch.so.0, and succesfully import my lib. But I am not sure if that makes my wheel less portable.

[jcannon-gplates]

I had the same issue with libGLdispatch and seg-faulting. And excluding libGLdispatch from auditwheel worked for me too.

But I am not sure if that makes my wheel less portable

I not sure if bundling libEGL in the wheel will work for all Linux distros - because I'm not sure whether GLVND is installed on all distros by default (see here) and your bundled libEGL might be relying on that. But it's not clear to me whether this is true or not.

My module linked against libOpenGL, not libEGL, but it's a similar GLVND issue. However, in my case I could switch to libGL and not have to exclude anything (with auditwheel). Apparently libGL is whitelisted by auditwheel (not copied into wheel by default), but libOpenGL/libEGL are not whitelisted. However, I guess you wouldn't be able switch libEGL to libGL (since libGL supports libGLX only). So not sure what the solution for libEGL is.

For others that come across this thread (and are using libOpenGL)...

In my case, a better solution was for my module to avoid linking to libOpenGL altogether, which naturally prevented libGLdispatch from getting copied into the wheel (and then I didn't have to exclude anything). Instead I now link to libGL. My project is CMake-based, so setting OpenGL_GL_PREFERENCE to LEGACY enabled this (the default is GLVND which links to libOpenGL).

Previously, my module was linking to libOpenGL but it also links to Qt5 which links to libGL. So I was linking to both libOpenGL and libGL. Now I only link to libGL.

As for why this works: Because libOpenGL is not whitelisted by auditwheel (presumably because it's not available on all Linux distros) it, and its dependency libGLdispatch (see here), get copied into the wheel. This explains the libGLdispatch-dcc1ca97.so.0.0.0 => /home/... part. Since libGL is whitelisted, it does not get copied. And hence its dependency libGLdispatch also doesn't get copied. This explains the libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 part. And so having two dispatch tables likely caused the seg-fault.

[HinTak]

libGLdispatch is an indirect dependency from libEGL. If you reverse patch libEGL, it disappears. See
pypa/cibuildwheel#2118