new virtualgl seems to break steam with bumblebee #16
Comments
|
Yeah, well, sorry to rant, but Arch Linux is incredibly difficult to support, because it is a constantly moving target, and it ticks me off that apparently they didn't release the beta version to give people a chance to test this stuff before the final VGL 2.5 release. All I can do is try my best to repro this with a more sane distribution. |
|
It doesn't fail in the same way on Ubuntu, but I can confirm that 2.5 + Steam is broken but 2.4.1 + Steam works. Will look into it. |
|
Correction: the failure I was experiencing (segfault) was due to a mismatch between my dev version and the system-installed version (i.e. LD_LIBRARY_PATH wasn't properly picking up my dev build.) Installing the 2.5 packages onto the system cleared up the segfault, and Steam launches. I cannot get past the login screen, because I am not a gamer and do not have a Steam account, but it seems that the failure you're observing is occurring before that point. So I guess I can't reproduce this. Not really much I can do unless this is reproducible with another distro. I've tried several times without luck to get Arch Linux up and running. Again-- moving target. Basically impossible to support from a software manager's point of view. If you can make this fail in the same way using another distro (Ubuntu 10-15, SUSE 11, CentOS 5-7, Fedora 22, Mint 17.2 are all things I can readily test), then I'm happy to look into it further. Otherwise, there isn't much I can do at this point except wait and hope that the problem manifests in some other way that I can reproduce. |
|
This might be related to the introduction of the nVidia GL vendor-neutral dispatch library in Arch. https://bugs.archlinux.org/task/48109. Seems it may not be fully baked, although I am able to install and use the GLVND just fine on CentOS (so Arch's implementation may be what isn't fully baked, not nVidia's.) |
|
I have this problem too. My wine report "err:wgl:has_opengl glAccum not found in libGL, disabling OpenGL.". And I have tried with GLVND and without GLVND. In both cases 2.5 doesn't work, but 2.4.1 works. |
|
@kasei-wang are you also using Arch Linux? This issue is tracking the failure with VGL 2.5 and the Linux version of Steam under Arch Linux. #15 is tracking the failure with VGL 2.5 and WINE under Arch Linux, but the issues may have the same root cause. |
|
Yes I'm using Arch. And I found a friend who using VGL2.5 on Arch without this failure. We are trying to find out the cause. Maybe I will report more information tomorrow or the day after tomorrow (UTC+8). |
|
In reading https://bugs.archlinux.org/task/48109, it seems that it may be related to upgrading both VGL and the nVidia drivers at the same time. Apparently something about the nVidia driver upgrade seems to have broken applications that load OpenGL symbols manually from libGL (as opposed to linking directly with it and letting the dynamic linker handle the symbol loading.) That includes VirtualGL, since that is how we load symbols from libGL as well. |
|
I rebuild VGL2.5 and bumblebee. Still does't work. Seems not that cause. |
|
Manjaro Linux, I have the same thing :( |
|
Confirmed that this is an Arch-specific packaging issue. They appear to have duplicated libvglfaker-nodl.so as libvglfaker.so, so effectively every time you invoke In the future, I will not be fielding requests for support on Arch, unless the issue can be reproduced on another platform. It took the better part of a day for me to just install it and get it limping along enough to test with it. It is completely non-intuitive for me, and this issue proves that it is rather thrown-together and not well tested. |
|
Temporary workaround: Run Steam with |
|
For the reccord : Starting steam with this command LD_PRELOAD=/usr/lib32/nvidia/libGL.so __GLVND_DISALLOW_PATCHING=1 optirun steam seems to works correctly on archlinux, with virtualgl 2.5 and bumblebee (intel/closed source nvidia driver). |
|
I am not sure what __GLVND_DISALLOW_PATCHING does exactly, but it makes sense that preloading libGL would work around the issue as well, because the root cause is that Arch isn't packaging the VirtualGL fakers correctly. Since they are only including the -nodl faker (twice), what happens is that VirtualGL tries to use dlsym(..., RTLD_NEXT) to load symbols from libGL, but it can't do that, because the -nodl faker isn't linked with libGL, and neither is the 3D application in this case. The -nodl faker is designed for use only with "simple" OpenGL applications that link directly with libGL (it's mainly included as a means of testing compatibility issues-- there are very few applications that actually require it), so if you use it with an application like Steam that doesn't link directly with libGL, then libGL will never be loaded into the process-- unless you explicitly load it (with LD_PRELOAD) or explicitly tell VirtualGL to load it (with VGL_GLLIB.) |
|
I can understand that you find Arch difficult to use. |
|
I finally got Arch up and running, so that's no longer the problem. But I'm just one person maintaining three rather complicated OSS projects. I cannot support every single distro on the planet. The problems with Arch, from my point of view:
In the future, if a bug is reported in VirtualGL on Arch, the first thing I will do is attempt to diagnose it on another distro of similar vintage, such as the latest Fedora or Ubuntu. Failing that, I will request that the submitter attempt to reproduce the bug using our official binary package (to eliminate downstream packaging bugs such as the one that prompted this issue.) Failing that, I will assume the bug to be Arch-specific and will not devote any significant time to diagnosing or fixing it until/unless it can be shown to affect another platform. Sorry, guys. This is unfortunately not the first time that I've been sent on a wild goose chase that turned out to be a downstream bug. I'm an independent developer, so time is money. |
|
Absolutely understable and I'm sure Arch users can live with that solution (lot's of DIY minds there). |
|
@dcommander I also use Arch and faced this issue, and decided to repack package myself to eliminate any posibily of maintainer's mistake here, so let me share my results here. Through tons of cmake logs, step by step, i've came to point, that changing line 93 in I don't know much about all that cmake stuff, but i think this issue could be related to some sort of changed behavior in cmake handling STREQUAL. PS: sorry for terrible grammar. |
|
Both 32-bit and 64-bit builds work fine for me using either CMake 2.8.x or the latest CMake (3.5) on a non-Arch platform. I don't think it's a CMake issue. I would suggest adding right above and see what the value of |
|
I've added debug output of
So, everything looks correct, but still i've got .so without libGL linked:
|
|
Try replacing with |
|
Just came to same conclusion. Tried it, but still no luck Also, i've added debug message inside that IF, and it showed up correctly |
|
That doesn't make sense, though. If you're seeing that debug statement, then obviously the if() statement is working correctly, so I don't understand why replacing it with Try |
|
Here is the part with linking:
|
|
Not sure why it's trying to link with |
|
Here it is - additional debug statement inside IF section, -DOPENGL_gl_LIBRARY removed
|
|
OK, so does the faker get linked properly when you remove |
|
Unfortunately, no. I'm trying to cleanup my whole system, and run package build again. |
|
Symbols in /usr/lib/libvglfaker.so was removed by "LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro“"(the --as-needed) in makepkg.conf on Archlinux. That's why when you compile without Arch's makepkg, it works. |
|
Catching up from these multiple developments and findings... thanks to you all! The issue as posted by me in Arch's bug reporting system is https://bugs.archlinux.org/task/48403?project=5... it draw no attention up to now but you might report your findings there. Daniel. |
|
Apparently there's a new packaging from Arch: virtualgl/lib32-virtualgl 2.5-2, I cannot test it at the moment unfortunately. |
|
I have test those virtualgl/lib32-virtualgl 2.5-2, works for me. |
|
We fixed the issue in Arch. A bit less hate from upstream towards our project would be appreciated. We actually try to be very compatible with upstream and very rarely downstream patch. |
|
@svenstaro I do this for a living. Maintaining VGL and other related open source projects is my only income source, so time is literally money for me. This issue, which turned out to be your problem and not mine, took approximately 15 hours of labor, for which I was not compensated. I seriously doubt that you spent 15 hours on the same issue, even though it was ultimately your bug. I simply cannot afford to do that kind of pro bono work unless it is ultimately benefiting the upstream project. VirtualGL has numerous large deployments around the world, but most of them are running RHEL, Ubuntu, or SLES. If I can't repro an issue on one of those platforms, then I can't get paid for fixing it. That doesn't mean I'm unwilling to fix issues that affect Arch, but it means that I need you guys to be really certain that the issue is mine and not yours. I frankly don't think you did due diligence on this. I'm not expressing "hate" toward you or Arch. I'm expressing frustration. I realize that Arch is out on the bleeding edge, so sometimes bugs will surface in Arch before they surface elsewhere. I realize that mistakes will be made, and that's fine. If you prefer Arch, that's fine too. But Arch is a "get-your-hands-dirty" sort of distro, so I expect that its users and maintainers will get their hands dirty. I expect that you will be the first line of support for your downstream package, not me. If an issue is reproducible with my packages (the official VirtualGL binaries), and particularly if it's reproducible on multiple platforms, then I'm happy to get involved. |
|
And note that about 10 of those 15 hours were spent simply figuring out how to install and configure Arch. And this is coming from someone who has nearly 20 years of professional experience with Linux programming and administration, someone who maintains virtual machines with about a dozen different distros. Some of the documented procedures for configuring certain things in Arch (I recall having a lot of trouble configuring a static IP, for instance) simply didn't work as advertised. |
|
Just came home from abroad and tested the new package, and it works like a charm! I would like to warmly thank all involved, of course dcommander who spent huge efforts in investigating this issue, all others who helped tracking down and of course svenstaro who is responsible for the Arch package! Cheers to all, all the best! |
…th --as-needed See: VirtualGL/virtualgl#16 https://bugs.archlinux.org/task/48403?project=5 https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/virtualgl Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=597378 Package-Manager: Portage-2.3.3, Repoman-2.3.2
On ArchLinux, after upgrading lib32-virtualgl and virtualgl to version 2.5, steam no longer work with bumblebee.
% optirun steam
Running Steam on arch rolling 64-bit
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(1454620878)
[VGL] ERROR: Could not load GLX/OpenGL functions
[2016-02-22 13:50:23] Startup - updater built Feb 4 2016 12:22:08
Note that steam do work if I start it without optirun (indeed, it use the intel gpu, which is slow).
Downgrading virtualgl to 2.4.1 as a workaround fix the problem.
The text was updated successfully, but these errors were encountered: