KDevelop 5.0 standalone executable for Linux

I am currently at the KDE sprint in Randa, Switzerland. There are about 40 nice people here, working on making KDE software awesome. This year’s focus is on deploying our software more nicely — on Windows and OS X, but on Linux as well.

The landscape around our sprint location

Especially for user-faced applications like KDevelop, it really makes a big difference whether you use today’s version, or the one from two years ago. Many people run quite old Linux distributions, which do not provide up-to-date packages for KDevelop. Another situation where it can be hard to use an up-to-date version of our software is when you are at your workplace or at a university computer pool, and do not have privileges to install software. Thus in this week, besides enjoying the landscape, I spent some time building a stand-alone KDevelop executable. It is available from here: http://files.svenbrauch.de/kdevelop-linux/. (Update: More up-to-date images are on kdevelop.org/download. I will occasionally publish test builds here though.) The version from 16th June 2016 contains the beta version of KDevelop 5 from the master branch, including the new clang-based C++ plugin and the Python 3 language support plugin.

After downloading, simply make the file executable (either by running chmod +x file or using your file manager’s properties dialog) and run it. If you try, please let me know if it worked and what distribution (and version!) you used — that would be interesting to know.

KDevelop standalone running. Very interesting to look at.

The executable is built by compiling all our dependencies (most notably Qt, a list of KDE Frameworks, and LLVM) on a very old system, in this case CentOS 6. Then all required libraries are installed into a directory, and the libraries they link against are copied there as well by a shell script. What is stripped out is the base system — glibc, libgl, libX, libxcb, things like that. The idea is that these libraries are forward binary-compatible, and by building on an old system and linking against old versions of those libraries, you can run the resulting programs on any more recent system. You could then simply tar up this tree, and include a script to update a few environment variables and launch KDevelop. A somewhat nicer variant of that, which was used for the above installer, is by using AppImage, which puts all the files into an ISO image and adds a startup header to make it look like an ELF binary. The startup header mounts the ISO using fuse, sets up a few environment variables, and runs the program.

This reminds me of something else I would be interested in: On your computer, do you have fuse installed by default? If that is not the case for a lot of systems, it might be worth publishing a tarball instead.

I did lots of other things at Randa too, but I’ll report on those in followup posts.

Hello Sven, AppImage maintainer here. Great work! Looking forward to meeting you in Randa this Saturday. By the way, users who don’t have FUSE installed can loop-mount the AppImage since it is an ISO9600-compliant file. Also, tools like KDE Ark can be used to unpack AppImages (well, at least when bug 363209 is solved), so I don’t think a tarball would be beneficial.

Thanks for the AppImage. It works well on Ubuntu 14.04 and I’m very glad I can now use an up-to-date KDevelop at work too 🙂

I do encounter two issues, of which I’m not sure if they’re bugs of KDevelop or related to the AppImage:
– The environment for external scripts is quite empty. The only variables set are XDG_DATA_DIRS, LD_LIBRARY_PATH, PATH, KDE_FORK_SLAVES and QT_PLUGIN_PATH (checked by creating an external script that simply calls ‘env’). Even HOME isn’t set.

– Using a dark color scheme (running a Plasma/KDE4 setup, Obsidian Coast application color scheme), the document tab titles are black by default (on a dark background). Colorizing the titles based on project affinity makes the tab titles readable again through some shade of green, instead of the default tab text color so it’s only a minor issue.

Overall I’m very impressed with how easy it is to use this AppImage – so thanks once more and keep up the good work!

Archlinux; KDE up to date (as of 18 June ’16; 64 bits indeed); loaded currently in use project non-ui, c++ );

Using it right now. But “CMake Project Builder” Plugin seems working only half way. Or I do not understand what “Project Builder” really stands for : Nowhere “New Project” can be found ( personally, I do create my own CMake projects manually btw, or by using KDEApp Template Wizard, but it is not the point here).

But overall, the Appimage works like a charm!

Thank you very much and congratulations. That is a priceless gift.
– Bretzelus

The quick find function (or whatever it’s called) seems very unstable. For example, entering ‘_’ in the search field immediately crashes the entire application for me. This is the only console output I get:

Things I can think of that might be relevant:
– I use vi bindings in the editor (so the search field I’m talking about is the one you get when hitting ‘/’ in vi mode
– My keyboard is Swedish, but I have en-us layout

$ ./KDevelop-20160620-x86_64.AppImage
kdevplatform.serialization: version-hint not found, seems to be an old version
kdevplatform.serialization: “The data-repository at /home/afiefh/.cache/kdevduchain/kdevelop-{37845e17-b6fa-4817-8000-95efab433c03} has to be cleared.”
Recreating ksycoca file (“/home/afiefh/.cache/ksycoca5_en_eOGIbPO6Arhf6+RFTmqZ8QeX_E0=”, version 303)
Menu “applications.menu” not found.
“applications.menu” not found in (“/etc/xdg/menus”)

Can you just try again? I have seen before that the old data repository is somehow not properly cleared on the first startup and then KDevelop segfaults. If it still happens, can you run in gdb and see what comes up as backtrace?

Why not continuing to propose a deb/rpm/whatever beside the AppImage ?
Looks like this encapsulation doesn’t support full theme integration (and I love to move my windows by clicking anywhere on it, and having seamless styles between apps), so I’m forced to compile it entirely just because of that..
btw, great job !

We never supplied debs or rpms. That was always done by your distribution — but for some distributions, only ages after the release. The AppImage is for when your distribution does _not_ provide up-to-date packages. It still should; nothing changes about that situation. The AppImage is an additional service.

We cannot build distribution packages ourselves — most of the formats are pretty terrible and require a lot of experience to work with, and there are, without exaggeration, about a hundred common distribution versions we would need to individually target. It’s not feasible.

And yes, we cannot load theme plugins from your system from the image, they are not guaranteed to be compatible.

I have been looking for a way to run KDevelop5 on an old system and an appimage seems like the best option. Only catch is the system does not have FUSE and I do not have root privilege so I cannot install it or use any other methods I have come across. Is there a way to run an appimage without FUSE or root access, or is at least one of them required?

Simply rename the file to kdevelop.iso, then you can open it as an archive with ark and extract it. After extracting, change into the directory and type ./AppRun to run KDevelop. Let me know if that works 🙂
Use the AppImage from kdevelop.org, it’s newer than the ones linked here.
You can also tar up the resulting directory and redistribute it if you want.

Thanks for the reply sven. That worked on a modern system, however on the old system (SLES11-SP2) that is my target it fails with a “cannot execute binary file” error. Do you think think that the system is too old for that AppImage, or that there is some other issue?

Yes, exactly. Your version of libXi.so is apparently too old. But I can try shipping that as well, and we can try our luck again. I’ll rebuild the image somewhere in the next few days, maybe not publish it on the KDE servers but certainly here.

Wow, thanks sven; truly above and beyond in helping a stranger 🙂 I will start looking into how to build and maintain an AppImage in the meantime since if we can get this to work it looks like I will need to maintain my own image given the antiquity of my target system. Also I used an actual email this time in case you would like to move this off of your blogs comments.

Nah, it’s fine, it is in my interest to have this image working on a wide range of systems and you’re helping a lot with that. So we both profit. 🙂
You shouldn’t have to maintain your own image — I’ll try to make the official version work for you. Your system is very old, but just at the edge of what could still work with a bit of poking. I’ll leave another comment when I updated the image.

Your experimental image starts to run, but is eventually aborted by XCB right after a window is created (the window is just a flash). I pasted the output to make it easier to read: https://paste.kde.org/pxsmfgbz6

Ah, the stupid GLX stuff. You can try unpacking the image like before, and then set KDEV_DISABLE_PLUGINS=KDevWelcomePage in the startup script before executing kdevelop. I think that’s the only one which does any GL stuff.

Apologies for the delay, your tweak got it running so I as taking some time to test it out. For the most part it runs however it frequently hangs when parsing files (background parser) and will not recover until the session information is deleted. Also hit a “./AppRun: line 35: 22075 Segmentation fault kdevelop $@” error once.

The semantic analyzer also generates a strange “Cannon’t initialize object of parameter type” error on some void rvalue function calls but that reproduces on a modern OS with official AppImage so it is not related to the old environment or the experiment AppImage you made for me.

Not to be rude, but it is good to hear it is not just my environment with problems with application hanging 🙂
Let me know when you think it should be fixed or if there is anything I might be able to help with.

It should definitely be fixed 🙂
But we know what the problem is (at least we know one big problem that causes hanging) and we’re discussing on how to resolve it best at the moment. Expect 5.0.1 somewhere in the next week which should hopefully fix it.

It’s really disappointing – sorry, but that’s what it is.
Eagerly we tried to run new kdevelop 5 on our company’s laptops, but that failed because of segfaults – hm, ok – that’s not the point here. Just now, at home I tried it again – and yup it came up – cool … so far. I opened a bunch of PHP-Scripts which used to be unreadable with the old Kdevelop 4.7.x because of wrongly marked parser errors due to missing support for language features introduced with PHP v5.6 from 2014. But with the new 5.0.0-1, announced as: “also comes with kdev-php”, nothing has changed! – Leaving kdevelop unusable for php development. Will there be any further support for PHP in the future, or has it be abandoned? If the latter, it should be announced – despite of being a free, open source project.

Re. PHP, I’ll be honest about that: the plugin is not discontinued, it is still being maintained, but it is not the thing which is under the most active development. The big thing which changed for 5.0 was the replacement of the cpp plugin by the new one; everything else has “just” seen incremental improvements.

Those laptops running debian sid with qt/kde packages on hold since kf5 migration in debian sid began – preventing also a lot of updates for non qt/kde packages . Just tried here 5.0.0-2 – nothing changed: “/tmp/.mount_0Y1IM7/AppRun: line 31: 8164 Segmentation fault”.
Glad to hear, the kdev-php is not discontinued. The still missing support even for previous versions (current is v7 …) made me fear worse.
Thanks for the quick reply.

You folks have done a great and hard work! I like KDevelop and although I use the official gentoo ebuild (=5.0.0), for testing purposes I like to download your latest AppImages. While KDevelop-5.0.0-1-x86_64.AppImage worked for me, none of the next did. The error message is “kdevelop: symbol lookup error: /usr/lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_request_with_fds”. As I mentioned it’s not an emergency for me, just for your information. Once again congratulations.

Hi, thanks for the info. I don’t understand that though. I ship libxcb-dri2.so.0 with the image, and I cannot find anything that links libxcb-dri3.so. Can you export LD_DEBUG=”libs” and then run the AppImage, and paste the resulting log somewhere?

If you prefer, replace the “raw” string with “show”. I found two fatal errors. One is about /usr/lib64/gconv/ISO8859-7.so and the other about libxcb-dri3.so. The second error says:
/usr/lib64/libxcb-dri3.so.0: error: symbol lookup error:
undefined symbol: xcb_send_request_with_fds (fatal).

I tried to find witch libraries/packages use xcb_send_request_with_fds like this: grep -r xcb_send_request_with_fds /usr/lib64 and found these:

Thanks for the info. Maybe we can take this to a bug report on bugs.kde.org? That’s a much better place to discuss.

I really don’t understand why it is looking for libxcb-dri3.so. I strace’d it on my system, it only loads libxcb-dri2.so — as it should, because that is what ships and that is what everything is linked against.

The only thing I can imagine is that it pulls in $library from your system and that by itself is already broken.

Yeah, I think it would be good if you’d just create a bug to track the issue, even if we end up setting it to “worksforme” right away. Maybe somebody else has the same problem and then we have it documented properly. Thanks.
Right now it feels more likely that you forgot to rebuild some package though … there is no mention of libxcb-dri3 in the AppImage at all, so if anything requests it, that has to be outside of the image and then the issue is on your system, not in the image. I was hoping I could read out of the LD_DEBUG output what file requires loading it, but somehow couldn’t. Can you try LD_DEBUG=”files” instead?

Unfortunately no, I don’t know … it’s high on the priority list for the AppImage to look into this, though. You will not be able to load style plugins from your system most likely, but everything else (colour schemes, fonts, …) should work somehow.