Bug 360552

Summary: krita3-prealpha3-de0d43d-x86_64.appimage will not start because of DRI3 XCB library dependency
Product: krita Reporter: ack0954
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: grave CC: griffinvalley, halla, jfebrer, micah.denn, strawberry
Priority: NOR    
Version: 3.0 Alpha   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description ack0954 2016-03-15 11:27:04 UTC
System Details:
Fedora 23, Linux version 4.4.5-300.fc23.x86_64, running amdgpu on Tonga hardware (Full FOSS stack), COPR repository griever/mesa-git for MESA built from GIT master and running in DRI3 mode by configuration

When running the appimage, or when appimage mounted and krita called with LD_LIBRARY_PATH pointing to its library:
./krita3-prealpha3-de0d43d-x86_64.appimage: symbol lookup error: /lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_fd

There do not appear to be any DRI3 libraries included in the appimage, only DRI2 libraries, so I'm assuming the distro this was made with was running DRI2 (still the default for most distros) and doesn't have the DRI3 XCB installed, and that when the DRI3 library is called instead, that call is deprecated and not there, or has been left out of the Fedora build.

Suggest enabling DRI3 on a system running what you build on and checking to see if it also breaks.  If it does not, suggest add /usr/lib64/libxcb-dri3.so.0 from that into your appimage so that it will override potentially broken ones on other systems.


Reproducible: Always

Steps to Reproduce:
1. Run DRI3 on system
2. Attempt to run krita appimage

Actual Results:  
Program fails to start

Expected Results:  
Startup program without the xcb error

System Details:
Fedora 23, Linux version 4.4.5-300.fc23.x86_64, running amdgpu kernel and XOrg on Tonga hardware (Full FOSS stack), COPR repository griever/mesa-git for MESA built from GIT master and running in DRI3 mode by configuration

libxcb-1.11.1-1.fc23.x86_64 - 
rpm -ql libxcb-1.11.1-1.fc23.x86_64
/usr/lib64/libxcb-composite.so.0
/usr/lib64/libxcb-composite.so.0.0.0
/usr/lib64/libxcb-damage.so.0
/usr/lib64/libxcb-damage.so.0.0.0
/usr/lib64/libxcb-dpms.so.0
/usr/lib64/libxcb-dpms.so.0.0.0
/usr/lib64/libxcb-dri2.so.0
/usr/lib64/libxcb-dri2.so.0.0.0
/usr/lib64/libxcb-dri3.so.0
/usr/lib64/libxcb-dri3.so.0.0.0
/usr/lib64/libxcb-glx.so.0
/usr/lib64/libxcb-glx.so.0.0.0
/usr/lib64/libxcb-present.so.0
/usr/lib64/libxcb-present.so.0.0.0
/usr/lib64/libxcb-randr.so.0
/usr/lib64/libxcb-randr.so.0.1.0
/usr/lib64/libxcb-record.so.0
/usr/lib64/libxcb-record.so.0.0.0
/usr/lib64/libxcb-render.so.0
/usr/lib64/libxcb-render.so.0.0.0
/usr/lib64/libxcb-res.so.0
/usr/lib64/libxcb-res.so.0.0.0
/usr/lib64/libxcb-screensaver.so.0
/usr/lib64/libxcb-screensaver.so.0.0.0
/usr/lib64/libxcb-shape.so.0
/usr/lib64/libxcb-shape.so.0.0.0
/usr/lib64/libxcb-shm.so.0
/usr/lib64/libxcb-shm.so.0.0.0
/usr/lib64/libxcb-sync.so.1
/usr/lib64/libxcb-sync.so.1.0.0
/usr/lib64/libxcb-xevie.so.0
/usr/lib64/libxcb-xevie.so.0.0.0
/usr/lib64/libxcb-xf86dri.so.0
/usr/lib64/libxcb-xf86dri.so.0.0.0
/usr/lib64/libxcb-xfixes.so.0
/usr/lib64/libxcb-xfixes.so.0.0.0
/usr/lib64/libxcb-xinerama.so.0
/usr/lib64/libxcb-xinerama.so.0.0.0
/usr/lib64/libxcb-xinput.so.0
/usr/lib64/libxcb-xinput.so.0.1.0
/usr/lib64/libxcb-xkb.so.1
/usr/lib64/libxcb-xkb.so.1.0.0
/usr/lib64/libxcb-xselinux.so.0
/usr/lib64/libxcb-xselinux.so.0.0.0
/usr/lib64/libxcb-xtest.so.0
/usr/lib64/libxcb-xtest.so.0.0.0
/usr/lib64/libxcb-xv.so.0
/usr/lib64/libxcb-xv.so.0.0.0
/usr/lib64/libxcb-xvmc.so.0
/usr/lib64/libxcb-xvmc.so.0.0.0
/usr/lib64/libxcb.so.1
/usr/lib64/libxcb.so.1.1.0

readelf -s /usr/lib64/libxcb-dri3.so.0.0.0

Symbol table '.dynsym' contains 37 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000cb0     0 SECTION LOCAL  DEFAULT    9 
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (2)
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND xcb_send_fd
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND xcb_send_request
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND xcb_wait_for_reply
     8: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND xcb_get_reply_fds
     9: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
    10: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    11: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (3)
    12: 00000000000011c0   104 FUNC    GLOBAL DEFAULT   11 xcb_dri3_buffer_from_pixm
    13: 00000000000014d0     5 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fd_from_fence_re
    14: 0000000000000fb0   108 FUNC    GLOBAL DEFAULT   11 xcb_dri3_open_unchecked
    15: 00000000000014f4     0 FUNC    GLOBAL DEFAULT   12 _fini
    16: 0000000000202000    16 OBJECT  GLOBAL DEFAULT   22 xcb_dri3_id
    17: 0000000000000cb0     0 FUNC    GLOBAL DEFAULT    9 _init
    18: 0000000000202010     0 NOTYPE  GLOBAL DEFAULT   23 __bss_start
    19: 0000000000001360   137 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fence_from_fd
    20: 0000000000202018     0 NOTYPE  GLOBAL DEFAULT   23 _end
    21: 00000000000014e0    19 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fd_from_fence_re
    22: 00000000000012b0    19 FUNC    GLOBAL DEFAULT   11 xcb_dri3_buffer_from_pixm
    23: 0000000000001110   175 FUNC    GLOBAL DEFAULT   11 xcb_dri3_pixmap_from_buff
    24: 00000000000013f0   108 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fd_from_fence
    25: 00000000000012a0     5 FUNC    GLOBAL DEFAULT   11 xcb_dri3_buffer_from_pixm
    26: 0000000000000ec0   105 FUNC    GLOBAL DEFAULT   11 xcb_dri3_query_version_un
    27: 0000000000202010     0 NOTYPE  GLOBAL DEFAULT   22 _edata
    28: 0000000000000f40   108 FUNC    GLOBAL DEFAULT   11 xcb_dri3_open
    29: 0000000000001460   108 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fd_from_fence_un
    30: 0000000000000e50   108 FUNC    GLOBAL DEFAULT   11 xcb_dri3_query_version
    31: 0000000000001230   104 FUNC    GLOBAL DEFAULT   11 xcb_dri3_buffer_from_pixm
    32: 0000000000001050   178 FUNC    GLOBAL DEFAULT   11 xcb_dri3_pixmap_from_buff
    33: 00000000000012d0   140 FUNC    GLOBAL DEFAULT   11 xcb_dri3_fence_from_fd_ch
    34: 0000000000000f30     5 FUNC    GLOBAL DEFAULT   11 xcb_dri3_query_version_re
    35: 0000000000001030    19 FUNC    GLOBAL DEFAULT   11 xcb_dri3_open_reply_fds
    36: 0000000000001020     5 FUNC    GLOBAL DEFAULT   11 xcb_dri3_open_reply
Comment 1 Halla Rempt 2016-03-15 17:14:53 UTC
Hm, this sucks... We're building CentOS 6.5, since that's the oldest distribution where Krita and dependencies will build. Does the portable linux version of Blender have the same problem? I'm not sure where to get dri3, I have to check whether centos 6.5 has dri3, but I'm on the train now.
Comment 2 Micah Denn 2016-03-15 18:16:45 UTC
is libxcb.so.1 excluded for the Appimage as suggested here?
https://github.com/probonopd/AppImages/blob/master/excludelist
Comment 3 Halla Rempt 2016-03-15 21:48:05 UTC
I made an experimental build without libxcb1 (but I see it has other xcb libs still).  Could you test it?

http://valdyas.org/~boud/krita-3.0-Alpha-master-edbb473-x86_64.appimage
Comment 4 Micah Denn 2016-03-15 22:48:27 UTC
(In reply to Boudewijn Rempt from comment #3)
> I made an experimental build without libxcb1 (but I see it has other xcb
> libs still).  Could you test it?
> 
> http://valdyas.org/~boud/krita-3.0-Alpha-master-edbb473-x86_64.appimage

That build works without issue for me.
(fedora 23, kernel: 4.3.5-300.fc23.x86_64)
Comment 5 ack0954 2016-03-16 01:31:53 UTC
The new build also works without issue on my machine.
Comment 6 Halla Rempt 2016-03-16 06:29:26 UTC
Okay, that sounds good -- I'll close this bug and make the next build (probably Sunday) with this recipe.
Comment 7 Josep Febrer 2016-03-21 19:25:49 UTC
I can confirm the same issue with Debian when using DRI3 with Intel graphics.
The new image also works here on Debian with DRI3.
Comment 8 ack0954 2016-04-09 19:09:42 UTC
./krita-2.99.89.appimage 
./krita-2.99.89.appimage: symbol lookup error: /lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_fd

Bug is back in the new alpha.
Comment 9 wolthera 2016-04-09 19:20:27 UTC
Yes, it is back because we're waiting for the appimage guy to get back to us.
Comment 10 Halla Rempt 2016-04-10 10:41:42 UTC
Please try again, I've updated the appimages.
Comment 11 ack0954 2016-04-13 02:14:11 UTC
Sorry, where did you update it?  The one on the page is identical to the original appimage I got (via diff).
Comment 12 LeStr4wberry 2016-04-13 20:26:22 UTC
(In reply to Boudewijn Rempt from comment #10)
> Please try again, I've updated the appimages.

It still doesn't work for me.

QCoreApplication::arguments: Please instantiate the QApplication object first
krita.lib.pigment: Compiled for arch: ::Vc::SSE41Impl
krita.lib.pigment: Features supported:
krita.lib.pigment: 	 "SSE2" 	---	 yes
krita.lib.pigment: 	 "SSSE3" 	---	 yes
krita.lib.pigment: 	 "SSE4.1" 	---	 yes
krita.lib.pigment: 	 "AVX " 	---	 no
our language ""
>>>>>>>>>>>>>> LANGUAGE "en_US"
./krita-2.99.89.appimage: symbol lookup error: /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0: undefined symbol: xcb_get_reply_fds


System details: Xubuntu 15.10, kernel 4.5, open source AMD drivers with DRI3 enabled (radeonsi, HD7770)

Same error also happens on: 
Xubuntu 15.10, kernel 4.2, open source AMD drivers with DRI3 enabled
Ubuntu Gnome 16.04/ kernel 4.4 / open source AMD drivers with DRI3 enabled
Ubuntu Gnome 15.10 / kernel 4.2 / open source AMD drivers with DRI3 enabled
Linux Mint 17.3 / kernel 4.2 / open source AMD drivers with DRI3 enabled
Linux Mint 17.3 / kernel 3.19 / open source AMD drivers with DRI3 enabled

The Krita appimage worked fine on all of the above configurations with DRI3 disabled (except for Ubuntu Gnome 16.04 - forgot to test, reinstalled too soon).
Comment 13 Halla Rempt 2016-04-15 06:39:21 UTC
Next time I forget to remove the right files, just ping me on irc :-)
Comment 14 Halla Rempt 2016-04-26 18:30:25 UTC
Could you all test http://files.kde.org/krita/3/linux/krita3-beta1-b0b613d-x86_64.appimage ?
Comment 15 Halla Rempt 2016-04-26 18:43:29 UTC
Okay, hold a bit, someone already found a problem.
Comment 16 Halla Rempt 2016-04-26 19:04:13 UTC
Okay, hopefully fixed (works here on OpenSUSE and Ubuntu 15.04): http://files.kde.org/krita/3/linux/krita3.0-beta1-b0b613d-x86_64.appimage -- please do test, though!
Comment 17 LeStr4wberry 2016-04-26 20:14:02 UTC
The updated version launched correctly!

However, I experience a weird issue when trying to run Krita appimages (alpha/beta) with updated drivers (from the Oibaf and Padoka PPAs). 

The issue in question: 

http://imgur.com/dsyfUvH
http://imgur.com/oej8Iy7

Basically, both on the canvas and within the program's interface (but NOT within the overview window) the hue values seem to have been swapped. 

This issue started happening only a couple of days ago, possibly when the PPAs started shipping mesa 11.3.0-devel. The stable version (2.9.11) is not affected.

Not sure if I should report this as a new bug (it doesn't seem to be reported yet) or is this a "running bleeding edge anything is bound to be risky" thing. :)
Comment 18 wolthera 2016-04-26 22:10:06 UTC
LeStr4wberry, could you make a new bug, and add to that the answer to the following questions?

1. Do you have ocio turned on maybe?
1b. If so, does turning it off affect anything?
2. What happens if you turn openGL off?
3. Graphics card and all the boring specs

That could really help with narrowing down the issue.
Comment 19 LeStr4wberry 2016-04-26 22:38:16 UTC
Thanks for the reply, Wolthera! 

It's past midnight here, so I'll fill the bug tomorrow morning. Just one question: by ocio do you mean OpenColorIO? (In which case, no, don't have it turned on. I'll do some more tests tomorrow. :) )
Comment 20 Halla Rempt 2016-04-27 07:04:32 UTC
Hum, if the splash screen's colors are wrong, then something _really_ weird is happening, since that's a QPixmap. I.e., Qt loads the xpm image and displays it, Krita's code isn't even involved...