503f8efbcd
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! |
||
|---|---|---|
| .. | ||
| arduino | ||
| beam-modules | ||
| bower-modules/generic | ||
| compilers | ||
| coq-modules | ||
| dotnet-modules/patches | ||
| eclipse/ecj | ||
| em-modules/generic | ||
| go-modules | ||
| guile-modules | ||
| haskell-modules | ||
| idris-modules | ||
| interpreters | ||
| java-modules | ||
| libraries | ||
| lisp-modules | ||
| lua-modules | ||
| misc | ||
| mobile | ||
| node-packages | ||
| ocaml-modules | ||
| perl-modules | ||
| pharo | ||
| pure-modules | ||
| python-modules | ||
| qtcreator | ||
| r-modules | ||
| ruby-modules | ||
| stm32/betaflight | ||
| tools | ||
| web | ||