Latest update (to 1.10-1~xedgers~saucy1) from xorg-edgers ppa results in crash upon starting any Wine application requiring OpenGL. Error message from debug log: err:wgl:has_opengl Failed to load libGL: /usr/lib/i386-linux-gnu/libxcb-dri3.so.0: undefined symbol: xcb_send_fd err:wgl:has_opengl OpenGL support is disabled. err:d3d_caps:WineD3D_CreateFakeGLContext Can't find a suitable iPixelFormat. err:d3d:InitAdapters Failed to get a gl context for default adapter Not specific to any particular (32bit) Wine version, tested in PlayOnLinux with various versions. System (from inxi): Kernel: 3.11.0-12-generic x86_64 (64 bit) Desktop: Gnome Distro: Linux Mint 16 Petra CPU: Dual core Intel Core i3-3110M CPU (-HT-MCP-) clocked at 1200.00 MHz Graphics: Card: Intel 3rd Gen Core processor Graphics Controller X.Org: 1.14.4.901 drivers: intel (unloaded: fbdev,vesa) Resolution: 1366x768@60.0hz GLX Renderer: Mesa DRI Intel Ivybridge Mobile GLX Version: 3.0 Mesa 10.1.0-devel
If you want me to guess: You somehow managed to install libxcb-dri3, but your libxcb version is too old for that. If that is in fact true, this is a problem of the xorg-edgers ppa. Does the following command find anything? $ nm -D /usr/lib/i386-linux-gnu/libxcb.so | grep xcb_send_fd Alternatively, you have an old version of libxcb.so laying around somewhere in your linker's search path. That's not a libxcb problem either.
I managed to install it simply by installing the latest updates from xorg-edgers, which didn't give any issues. Since they recommended going to bugs.freedesktop.org for bug reports, I ended up here. nm -D /usr/lib/i386-linux-gnu/libxcb.so | grep xcb_send_fd Did indeed not find anything, but it seems that I only have libxcb.so.1 instead. Creating a renamed libxcb.so then results in 00009340 T xcb_send_fd But that won't change anything about my issues. Instead I tried nm -D /usr/lib/i386-linux-gnu/libxcb-dri3.so.0 | grep xcb_send_fd which gave me U xcb_send_fd If you insist that it isn't your bug, I will try the edgers ppa again.
(In reply to comment #2) > nm -D /usr/lib/i386-linux-gnu/libxcb.so | grep xcb_send_fd > > Did indeed not find anything, but it seems that I only have libxcb.so.1 > instead. Oh, sorry, my fault. Yeah, just using libxcb.so.1 directly is fine. You can get rid of the renamed libxcb.so again. > Creating a renamed libxcb.so then results in > > 00009340 T xcb_send_fd > > But that won't change anything about my issues. Yes it does. It means that your libxcb.so.1 does define a symbol called xcb_send_fd(). Since you still have this issue, this means that you have another version of libxcb.so.1 laying around somewhere else that is older and does not have xcb_send_fd. For finding it I would suggest either "locate libxcb.so.1" or while exactly one wine app is running "pmap $(pidof wine) | grep libxcb.so". The first command finds all files called libxcb.so.1 and the later one looks at the things that wine loaded into memory and lists everything with "libxcb.so" in its name. (And please do not just randomly remove files that are laying around. I am just trying to help you figure out where that older libxcb.so comes from so that you can complain to whoever placed that file on your system) > Instead I tried > > nm -D /usr/lib/i386-linux-gnu/libxcb-dri3.so.0 | grep xcb_send_fd > > which gave me > > U xcb_send_fd This just means that libxcb-dri3.so needs a symbol called xcb_send_fd. The "U" here means "undefined" while the "T" from above stands for the "text section" which is where the symbol is defined. > If you insist that it isn't your bug, I will try the edgers ppa again. I don't think that its their bug either, but feel free to do that. I asked on IRC in #winehq and apparently wine doesn't bundle libxcb. So this extra libxcb.so does not come from wine...
Thanks for your answer! I used locate (since the affected Wine apps tend to crash directly), and got /usr/lib/i386-linux-gnu/libxcb.so.1 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0 /usr/lib/x86_64-linux-gnu/libxcb.so.1 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 which gives me the 32 and 64 bit variants, I guess. According to synaptic, all 4 files originate from the edgers ppa. I'm not so sure about an older version causing the issue anyway, since the issue only started after the update I installed yesterday. If it would be caused by an older version, shouldn't it have been there before? In the meantime I have filed another bugreport at Launchpad and notified the guy responsible for the latest edgers-update about it.
(In reply to comment #4) [...] (No more idea about the issue) > I'm not so sure about an older version causing the issue anyway, since the > issue only started after the update I installed yesterday. > If it would be caused by an older version, shouldn't it have been there > before? The update brought you libxcb-dri3 (and likely a newer mesa version which uses this library). Before, this library didn't exist at all. However, libxcb-dri3.so uses the new xcb_send_fd() API from libxcb.so. Somehow, your system loads a different version of libxcb.so instead and things go wrong. Before that upgrade of yours, all the needed symbols were also available in that other libxcb.so that must be hiding somewhere. > In the meantime I have filed another bugreport at Launchpad and notified the > guy responsible for the latest edgers-update about it. Thanks. It would be nice to provide a link to that issue (or to a solution, if found), so that anyone who finds this bug report via google knows where to look next.
Will do, should anything come out of it. In the meantime, thanks for your help.
one additional hint for other users: Steam ships its own copy of libxcb.so.1.1.0 which does not include the "xcb_send_fd" symbol. If you see this bug and have Steam installed, best check the '~/.local/share/Steam' folder for incompatible libxcb versions. Usually you can just rename these and restart Steam (however you have to remember to move the Steam versions out of the way after each Steam update).
I have the very same issue with libxcb 1.10 in Arch Linux x86_64. After running updatedb, I executed 'locate libxcb-dri3' and found only two libxcb-dri3.so in my system (the 64 and 32 bit versions), both in which xcb_send_fd is undefined. Previous to the update I was able to play Dota 2 and Portal, but now I can't.
(In reply to comment #8) > I have the very same issue with libxcb 1.10 in Arch Linux x86_64. > > After running updatedb, I executed 'locate libxcb-dri3' and found only two > libxcb-dri3.so in my system (the 64 and 32 bit versions), both in which > xcb_send_fd is undefined. Previous to the update I was able to play Dota 2 > and Portal, but now I can't. that symbol is defined in libxcb.so.1, not libxcb-dri3.
(In reply to comment #9) > (In reply to comment #8) > > I have the very same issue with libxcb 1.10 in Arch Linux x86_64. > > > > After running updatedb, I executed 'locate libxcb-dri3' and found only two > > libxcb-dri3.so in my system (the 64 and 32 bit versions), both in which > > xcb_send_fd is undefined. Previous to the update I was able to play Dota 2 > > and Portal, but now I can't. > > that symbol is defined in libxcb.so.1, not libxcb-dri3. Yes, you are right. But for some reason Steam is looking for that symbol in libxcb-dri3.so. I guess the bug is in Steam then.
The Steam Linux Runtime ships a version of xcb that's too old to contain this symbol; we're working on releasing an update that will address this.
In case anyone is interested or it may help someone, I link my bugreport from xorg-edgers at Launchpad here: https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1265642
If you opt into the Steam client Beta, this issue should now be fixed without needing a workaround.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.