I'm a big fan of this. But graphics driver libstdc++ conflict

Creating AppImages
1

Firstly, I really like the concept.

I have built an app image for my video player project on Ubuntu 12.04, the idea being this is the oldest platform I am targeting.

I’ve tested it and found it works fine on Ubuntu 12.04, 16.04 and Lubuntu 16.04.

Today I happened to test out my app image on Linux Mint 18.1 (based on Ubuntu 16.04) and I got an error launching my app:

oliver@Linux-Mint-Test ~/Desktop $ ./emu-player-64-1.0.5.appimage
Emu Player v1.0.5
libGL error: unable to load driver: vmwgfx_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: vmwgfx
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

It turns out this is a similar to a problem the games store app Steam has also had and seems to relate to the way some graphics drivers use a conflicting version of libstdc++ of something.

The solution is to prefix the launch command to tell it where the driver should find libstdc++
as follows:

env LD_PRELOAD=’/usr/$LIB/libstdc++.so.6’ ./emu-player-64-1.0.5.appimage

Now the application runs…

I’m not sure how directly this relates to AppImage as I’m a little bit of a Linux development newcomer but does anyone know what is best practice to workaround this problem so that the user doesn’t have to worry about it?

2

Just adding a little more information, it turns out that actually the libstdc++ I am supplying is newer than the one on Linux Mint (6.0.22 vs 6.0.21) and this is causing the libGL driver to fail to load. If I package 6.0.21 or let it use Linux Mint’s system library (also 6.0.21) then it works fine.

Perhaps it is a problem with the 6.0.22 I am shipping or a problem with the libGL driver - but I was under the impression that anything that relies on 6.0.21 would work happily if given 6.0.22…

Still, I assume the reverse is going to be an ongoing issue - i.e. if system drivers get updated on a target system that, say, rely on a 6.0.23 then my app isn’t going to work because it would only be supplying 6.0.22.

I could of course not supply libstdc++ at all, but then it might not work on older systems because my code relies on some C++11 features that older versions of gcc/libstdc++ don’t have.

I wonder if some kind of feature could be built into appimagekit where you could place libraries in an optional directory or somehow mark them as optional and it would only use them if they were later than the system one?

3

Hi @oviano, please check https://github.com/probonopd/AppImages/issues/173 and https://github.com/probonopd/AppImages/pull/185 and see whether it can solve this issue.

4

Yes that looks very interesting and relevant - I will investigate. Thankyou.

5

Do you have a download link of emu-player-64-1.0.5.appimage so we can investigate it?

6

Yes, you can get it from here:

https://emustream.tv/download.html

(EDIT: since my original post I have rebuilt it with gcc 5.4.0 and so it includes libstdc++.so.6.0.21, not 6.0.22)