libOpenGL.so.0 not deployed when running with -bundle-non-qt-libs

[alemuntoni]

Hi!

When switching from ubuntu 16.04 to 18.04 (with the last linuxdeployqt build), I noticed that libOpenGL.so.0 is not deployed and needs to be installed manually when running a deployed package. This was not necessary when deploying from 16.04. Is this intended?

This is an example workflow that builds and deploys the software, and then runs some tests in a clean machine: https://github.com/alemuntoni/PyMeshLab/runs/2490522243?check_suite_focus=true#step:4:66

As you can see, the deploy works as expected, but tests fail with the error:

ImportError: libOpenGL.so.0: cannot open shared object file: No such file or directory

Installing the package libopengl0 before running the tests solves the issue (commit and workflow), but this was not necessary when deploying from 16.04.

This is the deploy script that runs linuxdeployqt with the -bundle-non-qt-libs parameter.

[hcorion]

See AppImageCommunity/pkg2appimage#477
If your building using CMake do the following set(OpenGL_GL_PREFERENCE LEGACY)
@TheAssassin this issue is going to keep popping up as more people move their build systems to 18.04

[probonopd]

Installing the package libopengl0 before running the tests solves the issue

There is nothing that linuxdeployqt can do if a library needed by the application has not been installed on the system before linuxdeployqt is run. Hence closing here.

[alemuntoni]

Installing the package libopengl0 before running the tests solves the issue

There is nothing that linuxdeployqt can do if a library needed by the application has not been installed on the system before linuxdeployqt is run. Hence closing here.

@probonopd "Installing the package libopengl0 before running the tests solves the issue" was referred on my (already deployed) application tests, not on linuxdeployqt.

When running linuxdeployqt, all the libraries required by the application are installed (included libOpenGL.so.0). But libOpenGL.so.0 is missing in the final appdir.

[probonopd]

What in the AppDir is needing libOpenGL.so.0?

[alemuntoni]

In our apps (meshlab and pymeshlab) almost all targets (binaries, libraries and plugins) need opengl.
In our cmake configuration we use

find_package(OpenGL REQUIRED)

and the output in 18.04 is

Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so

while in ubuntu 16.04 was

Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so

I tried the solution suggested by @hcorion, but it seems not to work.
Before building the project, I am installing the following packages (I don't know if I'm missing something):

libglut3-dev freeglut3-dev mesa-common-dev libglu1-mesa-dev

libOpenGL.so has been deliberately excluded on linuxdeploy/linuxdeploy#152 in linuxdeploy, maybe something similar has been done also in linuxdeployqt?

[hcorion]

Hmmm, setting that worked for my project, I'd be curious to see the output of lddtree on the binary, I wonder if Qt opengl is trying to include it as well

[alemuntoni]

Nope, it seems that it is linked directly.. e.g. this is lddtree run on libmeshlab-common, which is used both by meshlab and pymeshlab:

libmeshlab-common.so => pymeshlab/lib/libmeshlab-common.so (interpreter => none)
    libQt5OpenGL.so.5 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libQt5OpenGL.so.5
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
            ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1
            libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
    libQt5Widgets.so.5 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libQt5Widgets.so.5
    libQt5Xml.so.5 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libQt5Xml.so.5
    libQt5Gui.so.5 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libQt5Gui.so.5
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    libQt5Core.so.5 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libQt5Core.so.5
        libicui18n.so.56 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libicui18n.so.56
        libicuuc.so.56 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libicuuc.so.56
        libicudata.so.56 => /home/runner/work/PyMeshLab/Qt/5.15.2/gcc_64/lib/libicudata.so.56
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0
        libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
            libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
    libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
            libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
                libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
                libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
                    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0
                        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
    libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

[alemuntoni]

Small update: after making sure that the cmake config of meshlab had the CMP0072 set to old everywhere, in order to use legacy opengl, there was still something that was linking libOpenGL.so. I am not sure if it is related to the fact that we need the target OpenGL::GLU...
Anyway, I was not able to get rid of libOpenGL.so in favour of libGL.so.

In the meantime, I am manually copying libOpenGL.so in the AppDir, as it is done in this commit of RPCS3. This workaround seems to work, at least on Ubuntu.

It would be great to know if libOpenGL.so on Ubuntu 18.04 is or is not a hardware-dependent library, and therefore if it is safe to get it bundled in an AppDir.

[hcorion]

We removed the manual addition in RPCS3 because it was causing issues with distros that already had a libOpenGL.so, it is unfortunately a distro-dependent library and will cause breakages. That's very strange that it just won't link against libGL.

As a better solution, I would recommend doing what the PCSX2 AppImage is doing https://github.com/PCSX2/pcsx2/pull/4103/files#diff-dab8bc68effd20fe4cf10daad595a9f919536bec53e406549cc331aa38f27392R13-R15
It's a bit of an ugly hack, but it'll work better on all distros, instead of just Ubuntu.

[alemuntoni]

Oh, ok.. Thanks @hcorion. I'll then revert that commit :D

Your hack seems fine just for AppImages, though.. In my case, the appdir is also "transformed" in a python library (with python bindings), and I am not sure that it could be done.. Apparently also Qt6 is having similar issues with libopengl.so.

I think that I'll end up with a warning to run sudo apt install libopengl0 before running the library on ubuntu...

[hcorion]

That's probably for the best for now until the AppImage folks come up with a better solution 👍

[arximboldi]

I am struggling with this very same issue. I really do not like the solution of asking people to install libopengl0 since this is the whole point of AppImage :)

In my case, I think the problem is that the Qt I am installing (from prebuilt binaries elsewhere) already links to libOpenGL. I am considering just using patchelf to change the reference libOpenGl.so.0 for something else. The question is: what is this something else? Should it be libGL.so? Or what else?

[hcorion]

Did you try setting set(OpenGL_GL_PREFERENCE LEGACY) in CMake? This is what we did to fix the AppImage on RPCS3.

[arximboldi]

Yes, sorry for the late reply but actually in the end I realized the issue was not coming from the prebuilt Qt binaries but from a CMake submodule I was linking against OpenGL, and I managed to fix it that way. Thanks a lot for the quick response also @hcorion !