Validating source files with sha256sums... ggerganov-llama.cpp-c3776ca.tar.gz ... FAILED
So, the llama.cpp submodule, which I understand is not necessary for the functionality anyway breaks the AUR package.
Git Clone URL: | https://aur.archlinux.org/codelite.git (read-only, click to copy) |
---|---|
Package Base: | codelite |
Description: | Cross platform IDE for C, C++, Rust, Python, PHP and Node.js written in C++ |
Upstream URL: | https://codelite.org/ |
Keywords: | C++ Editor IDE |
Licenses: | GPL-2.0-or-later |
Conflicts: | codelite-unstable |
Provides: | codelite |
Submitter: | None |
Maintainer: | uffe |
Last Packager: | uffe |
Votes: | 175 |
Popularity: | 0.44 |
First Submitted: | 2008-08-01 09:11 (UTC) |
Last Updated: | 2025-02-17 09:08 (UTC) |
Validating source files with sha256sums... ggerganov-llama.cpp-c3776ca.tar.gz ... FAILED
So, the llama.cpp submodule, which I understand is not necessary for the functionality anyway breaks the AUR package.
@janp: I think you need to open an issue at the CodeLite project itself - they are quite responsive. I would include the amimation showing the crash in the bug report. Link for issue creation here: https://github.com/eranif/codelite/issues
@janp: you could try the codelite-git (bleeding edge) AUR package and see if ~10 commits after release of 18.0.0 have changed the situation...
@janp: ok - on deeper inspection of the patch/fix that I pointed you to - I do not believe that it is related to your crash as the whole ConsoleLexer functionality was added (and subsequently fixed) after 18.0.0 release - apologies for the noise.
@uffe, it was probably a random crash and the option I added had no effect, since after a few attempts the same crash occurred again. I'll try the patch you suggested. Thank you.
@janp: Hmmm just found this - my guess is that you run into this issue - it was fixed after the 18.0.0 release. https://github.com/eranif/codelite/commit/4c54143990f93ba4eb6cd14ccfc8cbc9bddd052e
@janp: Quote: Moreover, I compared the binary wx libraries in the /usr/lib/codelite/ directory and the ones installed from the distribution package in /usr/lib and there are no differences.
Yes that is why I find it so wierd that it is needed - as you say it is just a local copy of the already installed system wx-libs...
@uffe... great, found it:
PID: 994813 (codelite) UID: 1000 (janp) GID: 1000 (janp) Signal: 6 (ABRT) Timestamp: Fri 2025-01-03 17:40:48 CET (4 days ago) Command Line: codelite Executable: /usr/bin/codelite Control Group: /user.slice/user-1000.slice/session-3.scope Unit: session-3.scope Slice: user-1000.slice Session: 3 Owner UID: 1000 (janp) Boot ID: 7ae7065c46c545b18d6dd19ce64bec8f Machine ID: 71bcc43e4ddb4f76828d79671833716d Hostname: noctowl Storage: /var/lib/systemd/coredump/core.codelite.1000.7ae7065c46c545b18d6dd19ce64bec8f.994813.1735922448000000.zst (present) Size on Disk: 10.3M Message: Process 994813 (codelite) of user 1000 dumped core. Stack trace of thread 994813: #0 0x00007456b00a53f4 n/a (libc.so.6 + 0x963f4) #1 0x00007456b004c120 raise (libc.so.6 + 0x3d120) #2 0x00007456b00334c3 abort (libc.so.6 + 0x244c3) #3 0x00007456b187f0e8 n/a (libwx_baseu-3.2.so.0 + 0x7f0e8) #4 0x00007456b004c1d0 n/a (libc.so.6 + 0x3d1d0) #5 0x00007456b1976b44 _ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent (libwx_baseu-3.2.so.0 + 0x176b44) #6 0x00007456b1976ede _ZN12wxEvtHandler11TryHereOnlyER7wxEvent (libwx_baseu-3.2.so.0 + 0x176ede) #7 0x00007456b1976f90 _ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent (libwx_baseu-3.2.so.0 + 0x176f90) #8 0x00007456b19770bb _ZN12wxEvtHandler12ProcessEventER7wxEvent (libwx_baseu-3.2.so.0 + 0x1770bb) #9 0x00007456b19778e2 _ZN12wxEvtHandler18SafelyProcessEventER7wxEvent (libwx_baseu-3.2.so.0 + 0x1778e2) #10 0x00007456b11ff72d _ZN12wxWindowBase22WXSendContextMenuEventERK7wxPoint (libwx_gtk3u_core-3.2.so.0 + 0x3ff72d) #11 0x00007456b1370c58 n/a (libwx_gtk3u_core-3.2.so.0 + 0x570c58) #12 0x00007456af878815 n/a (libgtk-3.so.0 + 0x78815) #13 0x00007456b08c882a g_closure_invoke (libgobject-2.0.so.0 + 0x1182a) #14 0x00007456b08f9565 n/a (libgobject-2.0.so.0 + 0x42565) #15 0x00007456b08e944f n/a (libgobject-2.0.so.0 + 0x3244f) #16 0x00007456b08e9f32 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32f32) #17 0x00007456b08e9ff4 g_signal_emit (libgobject-2.0.so.0 + 0x32ff4) #18 0x00007456afb5a7cd n/a (libgtk-3.so.0 + 0x35a7cd) #19 0x00007456af9e6aa5 n/a (libgtk-3.so.0 + 0x1e6aa5) #20 0x00007456af9e787b gtk_main_do_event (libgtk-3.so.0 + 0x1e787b) #21 0x00007456b0c4b457 n/a (libgdk-3.so.0 + 0x27457) #22 0x00007456b0ca7820 n/a (libgdk-3.so.0 + 0x83820) #23 0x00007456af70d559 n/a (libglib-2.0.so.0 + 0x5d559) #24 0x00007456af770257 n/a (libglib-2.0.so.0 + 0xc0257) #25 0x00007456af70e287 g_main_loop_run (libglib-2.0.so.0 + 0x5e287) #26 0x00007456af9e4ebf gtk_main (libgtk-3.so.0 + 0x1e4ebf) #27 0x00007456b1346ec6 _ZN14wxGUIEventLoop5DoRunEv (libwx_gtk3u_core-3.2.so.0 + 0x546ec6) #28 0x00007456b18b6a8b _ZN15wxEventLoopBase3RunEv (libwx_baseu-3.2.so.0 + 0xb6a8b) #29 0x00007456b18914e7 _ZN16wxAppConsoleBase8MainLoopEv (libwx_baseu-3.2.so.0 + 0x914e7) #30 0x00007456b18f5b31 _Z7wxEntryRiPPw (libwx_baseu-3.2.so.0 + 0xf5b31) #31 0x00005c0025f1ddff n/a (n/a + 0x0) #32 0x00007456b0034e08 n/a (libc.so.6 + 0x25e08) #33 0x00007456b0034ecc __libc_start_main (libc.so.6 + 0x25ecc) #34 0x00005c0025f2ef45 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64
Moreover, I compared the binary wx libraries in the /usr/lib/codelite/ directory and the ones installed from the distribution package in /usr/lib and there are no differences.
@janp: regarding stack-dump: maybe systemd has recorded the codedump for you...
Try coredumpctl list
, coredumpctl list codelite
and coredumpctl info codelite
Pinned Comments
uffe commented on 2016-09-26 11:42 (UTC) (edited on 2020-07-27 18:21 (UTC) by uffe)
ATTENTION: read this before flagging this package out-of-date
This package "codelite" represents the stable release of the codelite project.
I do not consider the "Weekly Builds" from http://downloads.codelite.org/ as stable releases (neither does the codelite project)
Generally speaking - this package will not be updated before the codelite release/download page (https://downloads.codelite.org/) have a new stable release published.
Please respect that - Thanks
PS: to clear up a recent misunderstanding - this does not mean that I won't accept patches that is needed for stable codelite to build against refreshed libraries etc
PS: I have added new "codelite-unstable" package to AUR that follows the weekly/latest builds from the codelite project.