epoxy: explicitly search libGL path as fallback #38168
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Success on x86_64-linux (full log) Attempted: epoxy Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: epoxy Partial log (click to expand)
|
|
cc @xeji -- look okay? |
|
@GrahamcOfBorg test sddm slim |
|
Failure on x86_64-darwin (full log) Attempted: epoxy Partial log (click to expand)
|
|
Failure on x86_64-linux (full log) Attempted: tests.sddm, tests.slim Partial log (click to expand)
|
|
Failure on aarch64-linux (full log) Attempted: tests.sddm, tests.slim Partial log (click to expand)
|
xeji
reviewed
Mar 31, 2018
| ''; | ||
| patches = [ ./libgl-path.patch ]; | ||
|
|
||
| NIX_CFLAGS_COMPILE = stdenv.lib.optional stdenv.isLinux ''-DLIBGL_PATH="${getLib libGL}/lib"''; |
There was a problem hiding this comment.
Limiting to linux might not be necessary with your patch, I had to do that because patchelf fails on darwin.
Let's see if this builds on darwin.
xeji
reviewed
Mar 31, 2018
There was a problem hiding this comment.
Patch looks good, should even work on darwin. Scary stuff though, and glibc provides zero official documentation on dlopen() ...
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!
dtzWill
force-pushed
the
fix/epoxy-libgl-path
branch
from
881433a
to
503f8ef
Compare
|
Bumped removing the bit that conditionally set |
|
Success on x86_64-linux (full log) Attempted: epoxy Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: epoxy Partial log (click to expand)
|
|
Failure on x86_64-darwin (full log) Attempted: epoxy Partial log (click to expand)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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!
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)I've tested this with a variety of NixOS tests on my dev branch,
confirming it fixes things w/musl and doesn't regress w/glibc.
FWIW the "slim" NixOS test actually is a good candidate for this,
as well as many qemu tests, by way of glamor--even though it
eventually fails to initialize in the successful case,
if it can't find libEGL.so.1 at all it errors out and test fails.
I've checked the "slim" test works as of this revision.