Tried to bundle KCalc, libGL errors

[probonopd]

linux@linux:~/makeaoi> ./testdir/AppRun 
libGL error: failed to get magic
libGL error: failed to load driver: r600

Runs anyway. At least on the source system.

[lvml]

It will probably also run on other target systems.
But it might be worth finding out whether also bundling DRM drivers for different GPUs is a good or a bad idea.
It is to be expected that software that tries to make use of nifty X11 features will at some point find that the X11 server they are connected to does not support that feature, and all reasonably written X11 clients will fall back to the "next best" method they see supported.
Just look at all the funny messages you get if you do something like ssh me@remote mpv somevideo.mp4 - loads of warnings what's unsuccessfully tried, but still presents a picture in the end :-)

[probonopd]

Yes, the current behavior is that it bundles the drivers for the very GPU on the source system. Either we should generalize or not bundle, I guess...

[lvml]

Both could be done by adding further entries into the "automatic file name filters" I mentioned in the README.md file.
However, before deciding in either direction, I think I need more experience when/how inclusion or non-inclusion of such drivers provide benefit or do harm.

[lvml]

I collected one piece of evidence that including DRM drivers might not be a good idea: They seem to use an abundance of weird, partially undocumented ioctl()s, which would require awkward reverse-engineering to pass through "fake devices".
Example I picked up when stracing subsurface:

15589 open("/sys/dev/char/226:128/device/drm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 14
15589 ioctl(14, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x48, 0x28), 0x7ffce7a4a1d0) = 0

(device 226:128 represents a Radeon RX 460 using the amdgpu driver)

[lvml]

Another piece of evidence against including DRM drivers: I succeeded to package "subsurface", which is based on Qt5, includes the GL-rendering "marble" code - and it works fine without the DRM stuff - and is still fast enough. (https://transfer.sh/2tLny/subsurface-4.6.4-2-x86_64.AppImage )

[probonopd]

Maybe you'd like to share your findings on http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface, too?

EDIT: Turns out you were faster than me, http://lists.subsurface-divelog.org/pipermail/subsurface/2017-July/029544.html

Thank you!