Re: Building KDE statically
- Date: Sat, 2 Mar 2019 07:09:43 +0800
- From: Jonathan Schultz <jonathan@xxxxxxxxxx>
- Subject: Re: Building KDE statically
Thanks I will take your suggestion and post this to frameworks-devel. I'll also put a quick note on okular-devel since okular is my target application for doing all this.
On 26/2/19 6:57 am, Albert Astals Cid wrote:
El divendres, 22 de febrer de 2019, a les 4:57:42 CET, Jonathan Schultz va escriure:
Hello KDE developers,
If anyone is interested, here is a brief report on something I have been working on in my spare time.
Since at least part of this involves frameworks, you may want to send this to the frameworks devel mailing list. Maybe you get some more answers/traction there.
TLDR: Here are some scripts to build KDE frameworks and okular statically using gcc/musl and cross-building for mingw: https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see the interesting stuff.
I've been working on an application based largely on okular that I would like to be able to deploy as simply as possible for users with no technical expertise. For this purpose, and despite its well-known down-sides I thought that a static build would be helpful.
So I started building KDE frameworks and other okular dependencies using kdesrc-build and working out what would need to change to make a static build. It turned out to be more painstaking but less complicated than I had imagined.
It all happens inside Docker containers built on voidlinux, which I chose because it handles musl natively and has a build process simple enough for me to understand. No doubt there are good reasons to use a different Linux distro but so be it.
Most of the patches are simply to make CMake handle static dependencies. A few deal with ad hoc issues that arose out of static building. The most complicated was linking okular's plugins statically, which involved a bit of build hacking, but nothing too dreadful (IMHO).
I've made all the patches backwards-compatible, ie they have no effect on a conventional build using shared libraries.
I took some shortcuts in working out which static libraries to include, ie basically all libraries are included on all link operations, and we count on the linker to leave out those that aren't required.
I also put in some cross-building stuff. Since kdesrc-build seems not to do a good job with host applications required for the building process, I just pre-built those and put the executables in the repository. Not all of frameworks cross-builds, but enough to link okular does.
What it produces:
An static okular executable with the following generator plugins: poppler, kimgio, dvi, tiff, xps, ooo, fb, comicbook, fax, plucker, txt is about 88MB in size. I understand that this might be reduced, possibly by as much as 80%, by using Link-Time Optimisation (LTO). Even as it is, it starts and runs noticeably faster than a conventional build. Cross-building, a mingw32 okular.exe is around 58MB and a mingw64 73MB.
Still some problems: it can't save files because (if I understand correctly) kio uses slave processes that are also based on plugins which would need to be linked statically.
What's next: Cross-building for MacOS. Using craft instead of kdesrc-build.
So feel free to hit me up with suggestions, interest or if anyone is interested in incorporating any of this into the mainline of KDE development.