Open hartwork opened 1 year ago
I've had a couple reports of this behavior recently, and I think both times the user was using the kitty
terminal emulator -- do you happen to be using kitty
? If so, a quick way to work around the issue is to use TERM=xterm-256color musikcube
when launching the app.
Hi @clangen I retried with latest b4035271319588624fb4425b4b2e317f1ec723cd, same crash. I have Yakuake here, based on KDE's Konsole, ${TERM}
is already set to xterm-256color
.
@hartwork show here what ldd-tree musikcube
prints. it looks like situation in #610 .
Hi @Gerodote interesting link, thanks! Compiling musikcube takes ages here, I can start a compile now and report back when it's finished… Could you help me understand why you closed #610 as completed? It seems like musikcube would still need a portable version of patch musikcube-3.0.1-tinfow.patch
to work out of the box?
@Gerodote PS: The build took about 30 minutes and is done now. Here's the output you asked for, annotations with !!!
I did manually on top:
# lddtree bin/musikcube
bin/musikcube (interpreter => /lib64/ld-linux-x86-64.so.2)
libcurl.so.4 => /usr/lib64/libcurl.so.4
libcares.so.2 => /usr/lib64/libcares.so.2
libnghttp2.so.14 => /usr/lib64/libnghttp2.so.14
libssl.so.3 => /usr/lib64/libssl.so.3
libcrypto.so.3 => /usr/lib64/libcrypto.so.3
libz.so.1 => /lib64/libz.so.1
libncursesw.so.6 => /lib64/libncursesw.so.6
libtinfow.so.6 => /lib64/libtinfow.so.6 !!!
libpanelw.so.6 => /usr/lib64/libpanelw.so.6
libtinfo.so.6 => /lib64/libtinfo.so.6 !!!
libmusikcore.so => /tmp/tmp.Gv9RLzJCAc/musikcube/bin/libmusikcore.so
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6
libm.so.6 => /lib64/libm.so.6
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1
libc.so.6 => /lib64/libc.so.6
Related commit is d723f963607788e2ea495f878c2cac2b171ae0a2 .
Hi @Gerodote interesting link, thanks! Compiling musikcube takes ages here, I can start a compile now and report back when it's finished… Could you help me understand why you closed #610 as completed? It seems like musikcube would still need a portable version of patch
musikcube-3.0.1-tinfow.patch
to work out of the box?
I thought it was gentoo related. I'll reopen it.
@Gerodote PS: The build took about 30 minutes and is done now. Here's the output you asked for, annotations with
!!!
I did manually on top:# lddtree bin/musikcube bin/musikcube (interpreter => /lib64/ld-linux-x86-64.so.2) libcurl.so.4 => /usr/lib64/libcurl.so.4 libcares.so.2 => /usr/lib64/libcares.so.2 libnghttp2.so.14 => /usr/lib64/libnghttp2.so.14 libssl.so.3 => /usr/lib64/libssl.so.3 libcrypto.so.3 => /usr/lib64/libcrypto.so.3 libz.so.1 => /lib64/libz.so.1 libncursesw.so.6 => /lib64/libncursesw.so.6 libtinfow.so.6 => /lib64/libtinfow.so.6 !!! libpanelw.so.6 => /usr/lib64/libpanelw.so.6 libtinfo.so.6 => /lib64/libtinfo.so.6 !!! libmusikcore.so => /tmp/tmp.Gv9RLzJCAc/musikcube/bin/libmusikcore.so libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 libm.so.6 => /lib64/libm.so.6 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1 libc.so.6 => /lib64/libc.so.6
Related commit is d723f96 .
maybe the patch that was mentioned in #610 can help you. or LD_PRELOAD= ... can help .
I thought it was gentoo related. I'll reopen it.
@Gerodote interesting point. I'm running Gentoo, not sure how many other distros use tinfow
and how many tinfo
without w
. Maybe you're right and it does need a fix in Gentoo or maybe it needs a fix in the other distros using it without w
? :shrug:
I'll link https://bugs.gentoo.org/692954 back to here…
I thought it was gentoo related. I'll reopen it.
@Gerodote interesting point. I'm running Gentoo, not sure how many other distros use
tinfow
and how manytinfo
withoutw
. Maybe you're right and it does need a fix in Gentoo :shrug:I'll link https://bugs.gentoo.org/692954 back to here…
if you are on gentoo, you can install musikcube from guru overlay with mentioned patch
This is with ncurses 6.4 and GCC 11.3.1.
Here's what I see in gdb:
The build went as follows:
Any ideas?