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.
Cheers,
Jonathan
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.
Cheers,
Albert
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.
Cheers,
Jonathan
