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
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.
is libxcb.so.1 excluded for the Appimage as suggested here? https://github.com/probonopd/AppImages/blob/master/excludelist
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
(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)
The new build also works without issue on my machine.
Okay, that sounds good -- I'll close this bug and make the next build (probably Sunday) with this recipe.
I can confirm the same issue with Debian when using DRI3 with Intel graphics. The new image also works here on Debian with DRI3.
./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.
Yes, it is back because we're waiting for the appimage guy to get back to us.
Please try again, I've updated the appimages.
Sorry, where did you update it? The one on the page is identical to the original appimage I got (via diff).
(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).
Next time I forget to remove the right files, just ping me on irc :-)
Could you all test http://files.kde.org/krita/3/linux/krita3-beta1-b0b613d-x86_64.appimage ?
Okay, hold a bit, someone already found a problem.
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!
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. :)
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.
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. :) )
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...