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!
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/zziplib/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzdir --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzdir --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem --version` and found version 0.13.69
- found 0.13.69 with grep in /nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69
- directory tree listing: https://gist.github.com/fec112f9114c98b118a59917224af5ff
This is only needed if built from the source repository, since we are
using the release tarball the generated manpage is included. This
removes the "wild" dependency on ruby very deep in the dependency tree.
(util-linux -> systemd -> libidn2 -> ronn -> ruby)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/gegl/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl -h` got 0 exit code
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl --help` got 0 exit code
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl -V` and found version 0.3.30
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl --version` and found version 0.3.30
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl -h` and found version 0.3.30
- ran `/nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30/bin/gegl --help` and found version 0.3.30
- found 0.3.30 with grep in /nix/store/fn6gs9ss2l0qpxyg3w5y76bx4wlgr9q6-gegl-0.3.30
- directory tree listing: https://gist.github.com/d252f515654f002ddf4d8f3301559e56
The isSeccomputable flag treated Linux without seccomp as just a
normal variant, when it really should be treated as a special case
incurring complexity debt to support.
It seems that all uses of `libva` it in nixpkgs except `mesa` and itself actually
either will gain from using `libva-full` instead of `libva-minimal` by default
or simply won't care.
* Implement libGL as a symlink package which uses libraries from libglvnd and
headers from Mesa (since ones from libglvnd are outdated).
* Use libGL_driver.driverLink treewide; add FHS paths where possible.
