undefined symbol: xcb_dri3_get_supported_modifiers

[FrostKnight]

There is supposedly a solution to said bug:

https://github.com/maxrd2/subtitlecomposer/issues/117#issue-386437932

Word for word this is what the op said:

Solution: Please do not bundle

'libxcb-dri3.so.0'
'libxcb-dri2.so.0'

References:

AppImage/appimage.github.io#964
probonopd/linuxdeployqt#331

I currently run into that issue and here is the full log on my Hyperbola Install:

sh: ldconfig: command not found nitrokey-app: symbol lookup error: /usr/lib/libGL.so.1: undefined symbol: xcb_dri3_get_supported_modifiers

Can you fix this in the next beta appimage?

I enjoyed using it when it worked. ;)

EDIT: the appimage works now, close if you wish.

[szszszsz]

Can you try Flatpak from https://github.com/Nitrokey/nitrokey-app/releases/tag/v1.4 in the meantime? cc: @enleth

edit: I meant Flatpak, sorry - corrected.

[szszszsz]

@enleth Hi! Could you check this issue and upload here latest/corrected AppImage?

[quiescentnexus]

We're not bundling any libxcb-dri* libraries, as referenced by the original issue - linuxdeployqt blacklisted them way back in 2018.

Some sources [1] dealing with a similar problem suggest removing all bundled libxcb components. Maybe that's something we'd want to test?

@FrostKnight can you link to an installer image of the distro version you're using? Figuring this out will be a lot faster if I just fire it up in a VM and see what works and what doesn't, but I need an environment that matches yours.

What I fear, though, is that a fix that works in your particular case might break the AppImage build on other systems. Judging from the Eagle bug report, the mix-and-match way AppImage bundles libraries and the way X11-related libraries in particular are evolving, the whole thing just seems very fragile and not as portable as we'd like it to be.

[1] https://forums.autodesk.com/t5/eagle-forum/can-t-run-eagle-on-debian-10-testing/td-p/8312348

[FrostKnight]

Erasing because, I realize now the problem was I kept trying to use make -j4 with a computer that has only a dual core processor. Pathetic right? Well probably a good thing I tried to make -j2 instead. Now it installs beautifully! :) So appimage and the source build from your out of source build work. This thread can be closed. :)

[szszszsz]

@FrostKnight One can't learn without mistakes :-) I do not see the direct causation chain here, but I am happy it works for you!

[FrostKnight]

the make + -j4 command I learned that the number aka 4 in this case runs at the speed of how many cores you have + 1. Because I compiled a web browser a similiar way from source and someone told me, make -j4 doesn't work on a dual core processor. ;-) I applied the same logic here, and viola it actually compiled.
I always got stuck on qmake guide where it said, make -j4 same with cmake guide... long story short, it is done and works!

Anywho, I thank you for your patience in this and other things.

[FrostKnight]

One last thing btw, will nitrokey-app require qt 5.9 or later in newer versions? Or is that only if I use qmake?