I setup a KDE Neon Git-Unstable VM to try building KDE from source so I could test C++ modifications to KDE Frameworks.

After installing all the dependencies to get kdesrc-build plasma-workspace to get 99% complete, I soon discovered that networkmonitor-qt would not build since libnm0 (managed by ubuntu) was v1.2 in xenial.

I’d been meaning to try the Neon update to bionic so I figured why not upgrade it. libnm0 in bionic is v1.10 which should fix the dependency issue. (Update: Neon is now shipping bionic by default now)

libudev.so is missing

After upgrading to bionic flawlessly, I ran kdesrc-build again. This time I ran into trouble with solid and kwin. Both build error logs mentioned:

make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libudev.so', needed by 'bin/libKF5Solid.so.5.51.0'. Stop.
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libudev.so', needed by 'bin/libinputtest'. Stop.

apt search libudev shows that libudev1 and libudev-dev are installed, so it’s not that. apt show libudev1 showed that it’s part of systemd btw. locate libudev.so had interesting output though.


It seems that it can’t find libudev.so in /usr/lib/, but it did exist in /lib. Well solid was compiling before the bionic upgrade, lets check my host OS KDE Neon User which is still on xenial.


So it looks like it’s got /usr/lib/x86_64-linux-gnu/libudev.so, lets see which package owns it with dpkg -S /usr/lib/x86_64-linux-gnu/libudev.so.

libudev-dev:amd64: /usr/lib/x86_64-linux-gnu/libudev.so

Welp. A glance at the file list on https://packages.ubuntu.com for xenial and bionic shows the removal of the /usr/lib libudev.so file.

For now, I’ll try symlinking the file to the one in /lib.

cd /usr/lib/x86_64-linux-gnu
sudo ln -s /lib/i386-linux-gnu/libudev.so.1 libudev.so

Running kdesrc-build plasma-workspace will now build everything without errors, huzzah!

plasma-desktop needs over 3Gb RAM to build

Now I tried building a few more packages with plasma-desktop. I first noticed it tried to rebuid everything plama-workspace needed as well, before finally trying to build plasma-desktop. After checking kdesrc-build --help, I realized I’d need to run the following every time I wanted to build a single package.

kdesrc-build plasma-desktop --resume-from=plasma-desktop

For now though, lets build plasma-desktop starting with plasma-workspace.

kdesrc-build plasma-desktop --resume-from=plasma-workspace

I ran into a new problem when building the plasma-desktop package.

virtual memory exhausted: Cannot allocate memory
kcms/keyboard/CMakeFiles/kcm_keyboard.dir/build.make:386: recipe for target 'kcms/keyboard/CMakeFiles/kcm_keyboard.dir/preview/geometry_parser.cpp.o' failed
make[2]: *** [kcms/keyboard/CMakeFiles/kcm_keyboard.dir/preview/geometry_parser.cpp.o] Error 1

Turns out I was running out of RAM! This time I ran kdesrc-build with KSysGuard open with the RAM graph visible.

Turns out building that package uses 1Gb more RAM than normal, climbing up to the max of 2Gb my VM is setup with. It also seems I forgot to properly setup the swap partition after resizing the partitions. Oops.

I first tried adding another gig of RAM to my VM, but even with 3Gb, it ran out.

So I formatted the swap and turned it on. Maybe it requires more RAM than normal if you build with 2 cpu cores.

After setting up the swap, everything built correctly.


The next step from building from source is appearently setting up a runtime environment. This involves creating a script that overrides a bunch of environment variables in the current Terminal session.

It mentions there’s extra steps for Plasma, but I was interested in what would happened if I run plasmashell now? Well I tested it with the following:

source ~/kde/.setup-env
killall plasmashell; kstart5 plasmashell

Suprisingly, everything loaded okay.