Fails (when run with any argument list) with "Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory". It's not linked against libGL, so I assume it is dlopening it.
mesa isn't the only provider of libGL.so.1, however.
virtual/opengl maybe. And something might be trying to open it instead of zathura itself
Good points. By running grep over the libraries zathura links against, it looks likely that media-libs/libepoxy-1.3.1 is the actual culprit. Looking at the libepoxy ebuild, I see that it DEPENDs on media-libs/mesa, which also seems suspicious. A quick search through the libepoxy source turns up the line
src/dispatch_common.c: /** dlopen() return value for libGL.so.1. */
So I think I'll change this to a libepoxy bug.
libepoxy is to be used by applications *already* using OpenGL.
gtk+ (a dependency of zathura) depends on libepoxy, but not an OpenGL implementation. Either gtk+ or libepoxy needs to depend on OpenGL.
media-libs/glew depends on virtual/opengl, so I guess that's what libepoxy should do as well.
leio, what do you think?
The bug has been closed via the following commit(s):
Author: Matt Turner <firstname.lastname@example.org>
AuthorDate: 2018-05-29 19:04:45 +0000
Commit: Matt Turner <email@example.com>
CommitDate: 2018-05-29 19:07:57 +0000
media-libs/libepoxy: RDEPEND on media-libs/mesa
The .pc file installed by libepoxy says it requires gl, which is
installed by Mesa.
media-libs/libepoxy/libepoxy-1.5.2.ebuild | 4 ++--
media-libs/libepoxy/libepoxy-9999.ebuild | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
*** Bug 657176 has been marked as a duplicate of this bug. ***