Package Details: codelite 17.0.0-0

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
Conflicts: codelite-unstable
Provides: codelite
Submitter: None
Maintainer: uffe
Last Packager: uffe
Votes: 174
Popularity: 0.000322
First Submitted: 2008-08-01 09:11 (UTC)
Last Updated: 2024-07-12 13:32 (UTC)

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.

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 17 Next › Last »

uffe commented on 2014-08-18 11:33 (UTC)

codelite have been working since its last update 2014-06-06 But extra/wxgtk was recently updated (2014-08-15) after that codelite will not start: $ codelite codelite: relocation error: /usr/lib/codelite/libplugin.so: symbol _ZThn600_N14wxTextCtrlBase8overflowEi, version WXU_3.0 not defined in file libwx_gtk2u_core-3.0.so.0 with link time reference

ioquatix commented on 2014-06-12 01:48 (UTC)

Why do you depend on libtinfo, shouldn't you just depend directly on ncurses? EDIT: Okay, so I just manually removed libtinfo and everything appears to be working fine (e.g. builds, runs). Perhaps this dependency can be made optional or removed?

dpriedel commented on 2014-06-06 15:58 (UTC)

In trying to build the 6.0.1 version the build would fail with unresolved symbol errors. I discoverd that the build was failing due to conflicts with an installed version of the codelite-bin package (which I had planned on removing after completing the build of this package). After removing codelite-bin, the build completed successfully. Thanks!! Dave Riedel

migrev commented on 2014-06-06 09:46 (UTC)

Updated to 6.0.1 and wxCrafter plugin now working (thanks Eran Ifrah @codelite for his help). @roheim: I have added lldb-svn as an optional dependendy, as it is actually not needed either for building or running, unless you explicitly want to use that debugger. But thanks for pointing it.

roheim commented on 2014-06-05 21:13 (UTC)

I would recommend to add lldb as a dependecy. http://codelite.org/LiteEditor/DebugWithLLDB

roheim commented on 2014-06-05 21:10 (UTC)

6.0.1 is out: https://github.com/eranif/codelite/releases/tag/6.0.1

migrev commented on 2014-06-05 12:10 (UTC)

Updated to 6.0. Found a workaround for the gcc 4.9 problems and will use it until the issue is fixed upstream. wxCrafter plugin is NOT working, as the Fedora build that previously did fails to find some symbols in wxGTK. Have just asked CodeLite upstream to make a wxCrafter.so build for Arch Linux, but we'll have to wait for a response. Also, added xterm as a depend as pointed by debio264.

migrev commented on 2014-05-20 11:25 (UTC)

I can confirm gcc4.9 problems. Looks like it is definitely an issue of wx3.0+gcc4.9. Will wait until a fix is found to bump version, including the 'xterm' dependency at that time.

npzaak commented on 2014-05-19 07:52 (UTC)

I have same issue debio264 has. I looked into this problem roughly and found strange behavior of gcc4.9. If wxCommandEvent instantiate in two or more functions, somehow gcc create the reference to "wxCommandEvent::Clone()" which is NOT used obviously. Furthermore gcc ignore the definition of wxCommandEvent::Clone() in class definition. It seems bug of gcc or problem of combination of gcc and other library, because some people can't reproduce it. I don't have so much time to investigate true problem, but I just found the workaround. Adding function call to wxCommandEvent::Clone in Plugin/search_thread.cpp can avoid this problem. (deleting cloned instance is also necessary.) But this is really dirty workaround...