How can I debug with gdb or something?
I tried "gdb qt6ct" but I think that it does not have debug symbols.
Is there some app with the symbols?
Nheko, strawberry etc. do not start because of "Segmentation fault".
I do not know what's the problem.
ARMtix is built w/o debug symbols. Could you try to rebuild locally? If it works then, i'll rebuild it
I built qt6ct-git and "Segmentation fault" again.
I also rebuilt another qt app and same problem.
Stating the obvious QT is complex and it's probable that the segfault is coming is coming from another part of QT not the actual programs you are starting seeing as it's happening with multiple QT programs.
Starting the programs with strace might shed some light ?
If it does you could try building the package that contains the problem component locally and installing the 'debug' version of its package.
Then, making sure that core dumps are enabled, you can use gdb to backtrace the coredump.
Now I was able to download the symbols.
gdb qt6ct
(gdb) run
Starting program: /usr/bin/qt6ct
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0xfffff240ef60 (LWP 26116)]
[New Thread 0xfffff1a0ef60 (LWP 26117)]
Downloading separate debug info for /usr/lib/qt6/plugins/platformthemes/libqt6ct.so...
[...]
Downloading separate debug info for /usr/lib/qt6/plugins/imageformats/libqsvg.so...
Thread 1 "qt6ct" received signal SIGSEGV, Segmentation fault.
0x0000fffff6675e18 in ?? ()
from /usr/lib/libQt6Core.so.6
(gdb)
Is that enough?
Other app that had debug in binary:
Thread 1 "<app>" received signal SIGSEGV, Segmentation fault.
0x0000fffff5075e18 in ?? () from /usr/lib/libQt6Core.so.6
(gdb)
Well both examples appear to show the segfault coming from /usr/lib/libQt6Core.so.6 , part of qt6-base.
If it's not a red herring you could try building qt6-base locally see if that helps?
If not try with different Flags in makepkg.conf. As in less optimization.
Search for "arm Segmentation fault libQt6Core" and similar.
I use kde on an ARMv7 chromebook. For a while now konsole segfaults not long after being opened. I've never been able to fix it :'(
Does build qt6-base take a lot?
Problem is that all qt apps do not start cause of seg fault, quite annoying.
That all depends on the device you are building it on and how ?
From memory only, I seem to remember it being a fairly big build but not as bad as some of the other QT components eg webengine
On my chromebook I use Distcc Cross-Compiling (https://archlinuxarm.org/wiki/Distcc_Cross-Compiling) which makes a big difference but again depends on the power of the client machine(s)
If you try Distcc I suggest the pre-built crosstool-ng toolchains. Building my own toolchain failed for me, but that's probably down to me only.
If you have powerful x86_64 machine, you could also try to build using qemu+chroot (i didn't succeed at that but someone on the forum did recently) or inside virtual machine
qemu+chroot? Not sure how that works.
I tried to make a VM but I could not boot.
I use just use a chroot to cross compile but my desktop is really not powerful.
But the aarch64 device is a PinePhone (very slow).
Error when building qt6-base from chroot:
Mimer .................................. no
ERROR: Feature "no_direct_extern_access": Forcing to "ON" breaks its condition:
NOT WIN32 AND TEST_no_direct_extern_access
Condition values dump:
WIN32 = ""
TEST_no_direct_extern_access = "FALSE"
CMake Error at cmake/QtBuildInformation.cmake:208 (message):
Check the configuration messages for an error that has occurred.
Call Stack (most recent call first):
cmake/QtBuildInformation.cmake:39 (qt_configure_print_summary)
cmake/QtBuildRepoHelpers.cmake:347 (qt_print_feature_summary)
cmake/QtBaseHelpers.cmake:219 (qt_build_repo_end)
CMakeLists.txt:32 (qt_internal_qtbase_build_repo)
I just built a qt5 app natively to test and:
Cannot mix incompatible Qt library (5.15.13) with this library (5.15.14)
How so?
There was a problem at ARMtix build system last month that led to some qt5 packages being incorrectly built. Could you check which qt5 package is broken for you?
The app that I built is auralquiz from the AUR.
Same error from extra/qstardict.
Not sure what apps from ARMtix repo use qt5.
The error you sent means that some qt5 dependency of that package is built against the wrong qt5-base version. Could you check which one can it be?
[...]
Downloading separate debug info for /usr/lib/libQt5X11Extras.so.5
Cannot mix incompatible Qt library (5.15.13) with this library (5.15.14)
Thread 1 "auralquiz" received signal SIGABRT, Aborted.
0x0000fffff6acd718 in ?? () from /usr/lib/libc.so.6
Like that?
usr/lib/libc.so.6 is owned by system/glibc 2.39+r52+gf8e4623421-1
I listed files owned by each installed qt5 package and tried to run the ones from /usr/bin. If it fails with such error - it requires rebuild
I have that error after building it.
Just after building auralquiz that error.
I searched qt5 apps in ARMtix repos.
I found etherwallet that does not start cause of missing libprotobuf.so.25.
Any suggestion to how fix qt5/6 apps?
As i already said, it is firstly required to find actually broken packages, which are qt5-* packages built against wrong qt5-base. Not etherwallet, just qt5-*. They are root of the problem, others are just a consequence.
Do I need to rebuild qt6-base for qt6 apps?
If it is just me having these problems I wonder why.
qt6 should be unaffected but you still can check qt6-* packages. It is not base which should be rebuilt, some other qt5-* packages are.
I find out about this problem because of qt6 apps.
After I checked qt5 just to see if that works.
I think that something is wrong normally you do not have segmentation fault in all qt6 apps and mismatching library for qt5 just after building the app.
Looks like a gcc and aarch64 bug: https://github.com/tsujan/Kvantum/discussions/999.
@phoenix_king_rus Can you build qt and kvantum with clang?
Also qt because when you open the file picker qt apps crash on aarch64.
As for qt - i'm not sure if it is really needed. It's a whole lot of rebuilds and i'll have to track all qt of packages on updates. Meanwhile you can overcome this segfault by using drag-and-drop feature
As for kvantum - i'll check it
Also, can you confirm that rebuilding with clang actually fixes problems?
I did not try this yet on ARMtix.
Having qt built with clang can help see if the bug with the file picker happens with gcc.
Adding this to build should work for kvantum.
build() {
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++It worked for pmOS.
ARMtix does not support my devices and so I had to tinker.
Then when I had this bug I decided to abandon ARMtix.
Now I may use it again.
@phoenix_king_rus I can confirm that building kvantum with clang fixes this.
Next qt update can you use clang? To see if it fixes the file picker bug.
As i said, rebuilding all qt with clang will require patching everything and maintaining these parches. Could you check if rebuilding only qt{5,6}-base can fix issue?