[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Building KDE statically
From:       Jonathan Schultz <jonathan () schultz ! la>
Date:       2019-03-01 23:09:43
Message-ID: e1611882-3e50-7b46-2582-713765fdc10e () schultz ! la
[Download RAW message or body]

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
> > 
> > 
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]