Fails to start with "Couldn't open libGL.so.1" (missing dependency?)

[Graham Clinch]

[Impact]
There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1.

[Test Case]
1. Deploy a server / cloud image of Xenial or Yakkety.
2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine.
3. sudo apt install firefox; firefox

Expected result:
firefox is launched on the client machine.

Actual result:
"Couldn't open libGL.so.1" message is printed.

[Regression Potential]
Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available.

[Other Info]
Original bug description:

virt-manager fails to start:

$ virt-manager --debug --no-fork
[Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork
[Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2
[Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory
$

Installing the 'libgl1-mesa-glx' package resolves the issue.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: virt-manager 1:1.3.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2
Uname: Linux 4.4.0-8-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
Date: Sun Feb 28 19:19:27 2016
InstallationDate: Installed on 2016-02-27 (0 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206)
PackageArchitecture: all
SourcePackage: virt-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David A. Desrosiers (setuid)]

This issue also affects attempting to run Firefox natively from within a clean, xenial/amd64 UCA image from Cloud Archive, with the same errors.

[Eric Desrochers (slashd)]

@Graham Clinch,

A potential workaround could be to install libgl1-mesa-glx package for the missing bits.

$ apt-file search libGL.so.1
...
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
...

[Dariusz Gadomski (dgadomski)]

According to my analysis this is a common issue for those gtk applications that don't depend on GL (so that e.g. libgl1-mesa-glx is not pulled in as a (in)direct dependency).

This is caused by a glXQueryExtension call inside Gtk function gdk_x11_screen_init_gl (gdk/x11/gdkglcontext-x11.c).

IMO ideally would be to detect in runtime if GL is available and skip this call otherwise. My gtk test build with this call commented out (ppa:dgadomski/firefox-lp1550983) seems to work fine.

I've been able to reproduce it also with Firefox, mousetweaks & gtk3-demo launched from a Windows client via cygwin with X on a server image with those apps installed with apt-get (none of them pulls in GLX implementation).
This seemed to work correctly from a Linux client ssh -X to the same machine. The control in this case skips this call - one frame above (_gdk_x11_screen_update_visuals_for_gl) gl visuals are found (from a local environment?) and used, so no crash happens.

Will look more into this.

[Dariusz Gadomski (dgadomski)]

This bug is fixed in Zesty by latest sync with Debian (gtk+3.0 (3.22.7-2)).

[Dariusz Gadomski (dgadomski)]

SRU proposal for Yakkety - backport from Zesty.

[Dariusz Gadomski (dgadomski)]

SRU proposal for Xenial - backport from Zesty.

[Dariusz Gadomski (dgadomski)]

Yakkety SRU proposal with fixed version number.

[Chris Halse Rogers (raof)]

Hello Graham, or anyone else affected,

Accepted gtk+3.0 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.18.9-1ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Graham, or anyone else affected,

Accepted gtk+3.0 into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.20.9-1ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Dariusz Gadomski (dgadomski)]

I have just verified it for Trusty and Yakkety on the same images that were used earlier to reproduce it.

The issue is gone.

[Robie Basak (racb)]

> I have just verified it for Trusty and Yakkety

I take it you mean *Xenial* and Yakkety? Please could you report the package names and versions that were tested to avoid any error?

[Dariusz Gadomski (dgadomski)]

Of course I meant Xenial and Yakkety. Thanks for noticing that Robie.

The versions I tested:
* Xenial
libgtk-3-0:
  Installed: 3.18.9-1ubuntu3.2
* Yakkety:
libgtk-3-0:
  Installed: 3.20.9-1ubuntu2.1

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+3.0 - 3.18.9-1ubuntu3.2

---------------
gtk+3.0 (3.18.9-1ubuntu3.2) xenial; urgency=medium

  * d/p/gdk-x11-Check-if-we-have-access-to-GL-before-using-G.patch:
    add proposed patch from upstream Bugzilla to let GDK X11
    initialization complete successfully when libGL.so.1 is not
    available (Closes: #847366, LP: #1550983)

 -- Dariusz Gadomski <email address hidden> Wed, 08 Feb 2017 15:58:40 +0100

[Robie Basak (racb)]

The verification of the Stable Release Update for gtk+3.0 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+3.0 - 3.20.9-1ubuntu2.1

---------------
gtk+3.0 (3.20.9-1ubuntu2.1) yakkety; urgency=medium

  * d/p/gdk-x11-Check-if-we-have-access-to-GL-before-using-G.patch:
    add proposed patch from upstream Bugzilla to let GDK X11
    initialization complete successfully when libGL.so.1 is not
    available (Closes: #847366, LP: #1550983)

 -- Dariusz Gadomski <email address hidden> Wed, 08 Feb 2017 16:53:03 +0100

[Paul White (paulw2u)]

Closing as all other bug tasks are showing "Fix Released"