Don't rely on questionable impact of DT_RPATH on dlopen().
This is a bit of a messy subject, but probably the clearest
reference to motivate *not* relying on how dlopen() behaves
in the presence of RPATH or RUNPATH is the following:
https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html
FWIW the dlopen() manpage only mentions the the RPATH
and RUNPATH in the "executable file for the calling program";
no mention of the executable files for libraries--
this has been brought to the attention of the relevant
parties and AFAICT nothing has been done.
The best reference for glibc behavior is
apparently to ... "try it and see".
Luckily a generous soul did exactly that
and reported the findings:
https://www.spinics.net/lists/linux-man/msg02291.html
Qt wrote on the subject a bit when they were bit by this,
linking to the above articles (directly or indirectly).
See:
http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/
--------
Since we know the path of libGL at build-time for libepoxy,
there's a simple solution we can use to avoid all of this:
simply teach libepoxy to explicitly look in the libGL path.
This commit patches libepoxy to accomplish this,
looking to "LIBGL_PATH" as a fallback if it cannot find
the libraries otherwise.
---------
This fixes use of libepoxy w/musl on NixOS!
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
- libepoxy dlopen()s libEGL / libGL but didn't have mesa in its runpath
-> error unless lib is already open or in LD_LIBRARY_PATH
- change dependency from mesa (should be avoided) to mesa_nonglu
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
