Move to libglvnd for OpenGL #37369
Closed
Move to libglvnd for OpenGL #37369
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
Move driverLink attribute there.
It's used for 3D acceleration inside qemu.
* 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.
In resulting derivation there's no mention of this path anyway (checked with grep).
Purely cosmetic.
This is needed for OpenGL support.
* Fix shebang so that it's usable on NixOS; * Enable warnings (they were enabled with Perl flag before); * Switch from mesa to libGL.
X libraries in LD_LIBRARY_PATH seem to not be needed anymore. I've tracked this addition as far as I could (02cef04) and they seem to be added for unfree NVIDIA and ATI drivers but at least for NVIDIA they are not needed anymore. We can add them with patchelf instead if it turns out to be the case with ATI.
Our patch which adds this envvar has been removed.
Also remove duplicate libGLU.
They seem to no longer be needed.
|
To boast a little: |
|
Testing and review much appreciated! I've rebased pushed our combined PRs to staging.
I've also moved `libva-full` to `aliases.nix` and updated `libva1` to use the same `{,-minimal}` convention.
Awesome! Many thanks.
@oxij To answer an old comment which I forgot to address earlier -- I didn't document `mesa_noglu` vs `libGL` because there's not much change in usage actually -- `mesa_noglu` is only needed when there're specific Mesa libraries you want to use (`libwayland-egl` etc.).
I'm not sure that's entirely correct, because you can, in principle, try to `-lGL` with `libGL` stubs and fail while not requiring any particular `libGL`.
|
|
@oxij Not sure I understood you, do you mean it's possible |
|
Ah, I see. It indeed is autogenerated from the XML OpenGL spec files (https://github.com/NVIDIA/libglvnd/blob/master/src/generate/gen_libOpenGL_exports.py). Then that's not an issue. Thanks for clarification.
|
gebner
added a commit
that referenced
this pull request
Apr 15, 2018
libGL.so is no longer in LD_LIBRARY_PATH since #37369
|
Is this indented that I have to add mesa_noglu to xorgserver now? |
8 tasks
9 tasks
|
This broke glfw and/or libepoxy, whichever one tries to find libGL.so.1. It also broke zsnes. |
|
On Sat, Sep 08, 2018 at 07:48:07PM -0700, Andrew Kelley wrote:
This broke glfw and/or libepoxy, whichever one tries to find libGL.so.1. It also broke zsnes.
Looks like following 5 lines need to be patched with full paths to
libglvnd libraries -- https://github.com/anholt/libepoxy/blob/master/src/dispatch_common.c#L192
(all other indirection/dispatching would be done there)
|
|
If there's a static executable that wants to work on all Linux platforms, how can it find OpenGL in such a way that it will find the correct version on NixOS? |
|
Static executables do not load dynamic libraries. Dynamically linked executables either load libraries from LD_LIBRARY_PATH environment variable or the rpath that is set in the executable (the latter one can be adjusted with patchelf) |
|
static executables can load dynamic libraries just fine. Here's a test case covering this behavior: https://github.com/ziglang/zig/tree/7c9f7b72c59e7c6de38038f512ae332fc164e8d7/test/standalone/load_dynamic_library on my system, in this dir: how is code supposed to know which one to load? |
|
This broke glfw and/or libepoxy, whichever one tries to find libGL.so.1. It also broke zsnes.
Can you give examples in "I run this, I get this error" format so I could try to reproduce those?
Can they just run pkg-config or something? Hardcoding library names with their versions looks rather strange to me.
|
|
On Sun, Sep 09, 2018 at 04:02:54PM -0700, Jan Malakhovski wrote:
> This broke glfw and/or libepoxy, whichever one tries to find libGL.so.1. It also broke zsnes.
Can you give examples in "I run this, I get this error" format so I could try to reproduce those?
I'd like to see "how-to-reproduce" as well.
> https://github.com/anholt/libepoxy/blob/master/src/dispatch_common.c#L192
Can they just run pkg-config or something? Hardcoding library names with their versions looks rather strange to me.
These names are standard and their sonames bound to api versions as
well.
Actually it have two solutions:
1. add libglvnd to `/run/opengl-drivers` (replace just link to
mesa-or-nvidia with link merged tree of all listed drivers). Personally I
prefer to have it configurable.
2. patch all GL loaders with full paths to libGL.so.1 and friends
(resolved to `${libglvnd}/lib`). Even if `libepoxy` load libGL
dynamically -- `libGL.so.1` still be explicit dependency, and full path
provide trackable source of it.
|
|
Here's a how-to repro: #46423 (comment) Also I double checked zsnes, and actually it was already fixed. My mistake on zsnes. epoxy still a problem though. |
|
Just migrated to 18.09 from 18.03, and have trouble with openarena package: It worked in 18.03. |
|
|
|
@Mic92 Looks like it just tries to locate the library that isn't there: Same for minetest package: I would appreciate if someone can explain how to point these to correct library or recompile, checking the store and pushing these off and back from configuration.nix was fruitless. Strangely, another Opengl application - Zandronum, works. Glxinfo works as well. |
9 tasks
|
But minetest works on master, so it definelly different problem |
|
This change seems to have broken most all OpenGL-based things in Rust, given that Edit: Adding |
I think this is a valid point. I'm working on a game and I'm looking to do static linking to maximize portability between distros. A common practice when distributing games is to dlopen libGL to fetch all the available opengl function pointers. It seems like this assumption is no longer valid? If I was a game developer attempting to target most linux distros what would I do? Please don't say steam runtime :| |
|
I think I was confused, it doesn't look like you can do what I was looking to do. I think if I just link SDL2 and use the load functions from there it should be fine... |
|
@jb55 at least we have both SDL and SDL2 correctly patched to find all libraries in nixos in proper places. If you plan closed source game -- maybe env variable can be good level of indirection? |
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.
Motivation for this change
Removes somewhat need for LD_LIBRARY_PATH in NixOS (it's still left for other usecases but it would be much more simple to get rid of it now)(actually not because GLX vendor implementations are searched by name -- it would be needed to patch those too. Still, at least no libraries should be overridden now withLD_LIBRARY_PATHin usual case, it should be only used fordlopensearch);libGLandmesa_noglu.out;Fixes libGL not working on non-NixOS (without setting up) #9415 with newer video drivers.(actually not becauselibc/libstdc++would still mix -- it needs something akin tolibcapsule. Would help with simple cases though)Besides doing the move itself I've done two more changes:
display-manager.service'sLD_LIBRARY_PATH; see commit message for why was it done. tl;dr: it seems to not be needed anymore so this is a cleanup.virgldriver to Mesa and OpenGL support to Qemu. This still doesn't work (Qemu segfaults when using OpenGL support and trying to get virgl acceleration) but hopefully we won't need another mass rebuild to fix this. Initially I wanted to use it for testing this change.Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)Tested on:
This can break packages; usual fix is to add
mesa_noglu(forgbm,driand other dependencies) orlibdrm(it was propagated before I think).cc @vcunat (I remember you tried this some time ago).