Segmentation fault: bzflag and Red Eclipse fail to run on non-NixOS, likely Mesa version mismatch #9840
Comments
The difference is that OpenArena is compiled by the upstream project, but bzflag is compiled by Nixpkgs. @vcunat I thought we should ping you on this because of the Mesa issue. It looks like the Nixpkgs Mesa's libGL is incompatible with proprietary drivers on non-NixOS systems. I think there must be a way to resolve this because it works on NixOS and the OpenArena upstream folks seem to have compiled a cross-system executable somehow, but I really don't know anything about Mesa. |
|
I believe that system libGL should load system libs for its own use, not our libs (therefore I believe your approach is wrong). The libGL itself has a fairly stable ABI – that's why games distributed in binary form do work over a wide range of GL versions and vendors. |
|
@ttuegel I don't know very much about what |
|
@joepie91 If you run |
|
Doesn't look like the It doesn't look much better for OpenArena, when adding the wrapper script variables: One thing I realized for OpenArena, taking into account its wrapper script (displaying the LD_LIBRARY_PATH): I'm not sure whether that's right. |
@vcunat How can we make that happen? The Nix ld.so does not look in the default system paths, and the host libGL doesn't have any RPATHs set. I thought we could |
|
I'm sorry, I confused your intentions. @joepie91: make sure you're using |
|
Hmm. Using Nix' And |
|
So, likely we need to add I'm still not completely certain that what we aim for is the best way, but currently I can't directly see a better one. |
|
Hm. It doesn't seem to work, even with a 'clean' copy of libGL: (I checked the ld-linux path, the one that is used above exists.) |
Shared libraries don't have interpreters, only executables. The executable in this case was compiled by Nixpkgs. |
@joepie91 This is almost certainly (part) of the problem. Can you check where the unmodified libGL gets libX11 from? That path will need to be added to the RPATH of the modified libGL. |
|
That would be, for host ... so, that doesn't really tell us much more... |
|
@joepie91 Huh? That can't be right, the list of required libraries must at least be the same, regardless of what linker you use! |
|
Perhaps |
|
@joepie91 Oh, nevermind, it's because Nix's |
|
Ah, I see. The command I used was: Here's the previous output, without |
|
OK, something doesn't add up here. You patched libGL with
But when you run Nix ldd on the patched libGL, it can't find libX11. Yet, your system ldd finds libX11 in /usr/lib64:
What happens if you run you system ldd on the patched libGL? |
And I just verified that the Nix |
|
Oh! I understand now. The modified RPATH of libGL doesn't affect the search path for libX11, because it's not a direct dependency; it's only a dependency of libXext, which we have not modified. Let's try adding an explicit dependency on libX11 to libGL: If that doesn't work, we'll likely need to add a patchelf'd version of libXext. |
Am I supposed to provide an absolute path to |
|
@joepie91 No, we're just adding the text "libX11.so.6" to the list of dependencies in libGL. That means it can't find libGL, for some reason... |
|
|
|
Hmm. I don't think my version of |
|
No, I don't think it does. It should be possible to copy and patchelf |
That's possible, but I'd like to avoid it: it will also force things compiled in Nixpkgs to use that libX11, which will probably just cause more segfaults. |
|
I would think it's possible for libGL to use a different libX11 than the ELFs using that libGL, but I don't remember the linking mechanism anymore. |
It is, but we are overriding libGL with LD_LIBRARY_PATH. If we put libX11 on the same path, we will override that, too. That's why we're setting RPATH for libGL, so it can use its own libX11. |
|
After installing an experimental version of ... this is the result: ... compared to pre-patch: ... so I guess that this is going to be a recursive problem. |
|
@joepie91 Yes, the "correct" solution here is to find all the libraries that get loaded when you run the host ldd on libGL (except linux-vdso.so and ld-*.so) and add them explicitly to libGL. |
|
After doing this: ... this is the result: Looks good to me - going to have a look at whether it Actually Works. |
|
Hmm. It still doesn't work for Red Eclipse - it still segfaults, and Not really sure what's going on here. |
|
That's because redeclipse probably also depends on libX11 and friends, and those load before libGL, so the linker reuses the already loaded ones. We should set the absolute paths to the required libraries in libGL instead, e.g. |
|
It still segfaults, unfortunately. On a clean copy of libGL: [...] |
|
@joepie91 Your libGL also needs libXext. |
|
That doesn't seem to fix it. Latest |
|
It looks good to me: Is it still segfaulting? |
|
Yeah.
|
The error code here (
This is that library that it's trying to |
|
Yes, libGL loads drivers by |
|
I think this way is probably a dead-end. The easiest way forward would probably be to use the Catalyst libGL in Nixpkgs. There's an option to build just the libraries, so you should be able to use it with your host kernel module. The kernel driver interface should be very stable (e.g. I know it's stable between 32- and 64-bit kernels), but if it doesn't work out-of-the-box, you would only have to modify the package to use the same version of Catalyst as is on your system. |
|
(triage) what’s the status? |
|
This is as fixed as it will ever be on the Nixpkgs side. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After spending a lot of time yesterday debugging things with @ttuegel, it seems that there's a Mesa version mismatch issue between Nix and my OS, leading to certain games segfaulting on boot.
Whereas nixpkgs uses a
10.xversion of Mesa, my system uses a9.xversion - specifically:Build commands used for OpenArena, bzflag and Red Eclipse:
Red Eclipse is a package I'm working on, it is not currently in nixpkgs. The package in its current state:
Both bzflag and Red Eclipse fail in the same way:
The
LD_LIBRARY_PATHis using this method of linking against the system-native libGL, rather than using the Nix-packaged one (as this is a non-NixOS system).However, upon discovering that the regular libGL on my system is actually not in
/usr/lib64but rather in an fglrx-specific directory (and using the one in/usr/lib64would only give access toswrast), I wrote afind-lib-gl.shas follows:Which in my case outputs:
... and I copied and patched that file into my shim directory, instead of
/usr/lib64/libGL.so.1.OpenArena does work with my newly patched libGL, but bzflag and Red Eclipse do not. It's not clear to me where the difference is.
gdboutput for Red Eclipse (running fromresult/lib/redeclipsedirectly, because of how Red Eclipse looks for its data and configuration files):The linking (through the shim) does appear to work correctly. Here is the
lddoutput, using the Nix-providedldd, and taking into account the environment that is set up by the wrapper script(s).OpenArena:
Red Eclipse:
bzflag:
CCing @vcunat on this, as suggested by @ttuegel.
The text was updated successfully, but these errors were encountered: