[reposted from kde-devel] Building KDE statically
Hello KDE developers, If anyone is interested, here is a brief report on something I have been working on in my spare time. 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
[Differential] [Commented On] D2075: Fix bug in kfiledialog.cpp that causes crashing when native widgets are used.
jonathans added a comment. I wrote the first patch to be as minimal as possible and to be consistent with the previous coding style. I therefore left the early returns in place. I wrote the latest patch based on my interpretation of your (@kfunk) feedback that it makes more sense to test d->w than d->native. Because implementing this involved a change to the existing coding style I took the liberty of writing it according to what I believe to be good coding practice. Early returns are suitable for dealing with erroneous or trivial cases, but less so when dealing with modes of operation, as in this code. They interrupt the logical flow of the code, and because the conditionally executed code no longer sits inside an indented block, make it less evident to the reader that it is conditionally executed. Actually thinking about this code a bit more closely, I would now take the position that the earlier practice of only testing d->native is more sensible. What is happening here is that kfiledialog has two modes of operation: native and non-native. This mode is reflected in the two variables d->native and d->w, of which only one should ever be non-null. Which of the two variable the code tests now (ie with the latest patch) varies from case to case, which makes it inconsistent. Moreover the meaning of d->native is self-explanatory, unlike d->w. Although testing d->w would avoid segmentation faults if both d->native or d->w were null, the fact is that if that ever happened there would have to be a serious problem anyway and the code would be obviously broken. Trapping a segfault with a debugger would actually make it easier to locate the problem than, for instance, a file dialog window simply failing to be displayed. But that's all going off on a tangent. Whatever your call is on this case I'm happy to accept. REPOSITORY R239 KDELibs4Support REVISION DETAIL https://phabricator.kde.org/D2075 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jonathans, #frameworks, dfaure, kfunk Cc: kfunk, aacid
[Differential] [Updated, 122 lines] D2075: Fix bug in kfiledialog.cpp that causes crashing when native widgets are used.
jonathans set the repository for this revision to R239 KDELibs4Support. jonathans updated this revision to Diff 10021. jonathans marked 2 inline comments as done. jonathans added a comment. Restricted Application added a project: Frameworks. Found a couple of places in old code where d->w made more sense than d->native to test. Also figured out why the repository got lost last time... REPOSITORY R239 KDELibs4Support CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2075?vs=10020=10021 REVISION DETAIL https://phabricator.kde.org/D2075 AFFECTED FILES src/kio/kfiledialog.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jonathans, #frameworks, dfaure, kfunk Cc: kfunk, aacid
[Differential] [Commented On] D2075: Fix bug in kfiledialog.cpp that causes crashing when native widgets are used.
jonathans added a comment. Apparently updating the diff has had the side-effect of: > https://phabricator.kde.org/source/kdelibs4support/ KDELibs4Support as the repository for this revision. Please excuse my bumbling - I don't know why that happened or how to repair it. :( REVISION DETAIL https://phabricator.kde.org/D2075 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jonathans, #frameworks, dfaure, kfunk Cc: kfunk, aacid
[Differential] [Updated, 76 lines] D2075: Fix bug in kfiledialog.cpp that causes crashing when native widgets are used.
jonathans removed R239 KDELibs4Support as the repository for this revision. jonathans updated this revision to Diff 10020. jonathans added a comment. Following @kfunk comments, I've changed the patch to test d->w rather than d->native, and used nullptr instead of 0 where appropriate. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2075?vs=4921=10020 REVISION DETAIL https://phabricator.kde.org/D2075 AFFECTED FILES src/kio/kfiledialog.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jonathans, #frameworks, dfaure, kfunk Cc: kfunk, aacid
[Differential] [Commented On] D2075: Fix bug in kfiledialog.cpp that causes crashing when native widgets are used.
jonathans added a comment. Agreed that would be more robust. In writing the patch I was seeking consistency with those functions that already did the test, so those would also need to be updated. Are there any situations where the two tests would yield a different result, ie d->native is true and d->w is non-null? REPOSITORY R239 KDELibs4Support REVISION DETAIL https://phabricator.kde.org/D2075 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jonathans, #frameworks, dfaure, kfunk Cc: kfunk, aacid
Bug in kdelibs4support/kio/kfiledialog
Sorry for cross-posting, but kde-frameworks-devel seems to be a more
active list than kde-devel where I previously raised this issue.
I'd like to file a bug report for kdelibs4support/kio/kfiledialog but
don't seem to be able to find a relevant category in KDE Bugzilla. If
someone can point me in the right direction I'll go ahead with that. In
the meantime, here is a description of the bug:
In short, some functions do not check whether d->native is non-null
before calling a method belonging to the file chooser widget d->w.
However, d->w is only set if d->native is null, so if this is not the
case then the application crashes. This issue manifested on a windows
build of kf5/okular by the application crashing in
KFileDialog::setMimeFilter when the user attempts to opena file.
However, I see that there are another half-dozen or so functions that
have the same problem.
In any case I made the following patch and confirmed that with it okular
can open files without crashing:
> --- a/src/kio/kfiledialog.cpp
> +++ b/src/kio/kfiledialog.cpp
> @@ -326,8 +326,6 @@ QString KFileDialog::currentFilter() const
> void KFileDialog::setMimeFilter(const QStringList ,
> const QString )
> {
> -d->w->setMimeFilter(mimeTypes, defaultType);
> -
> if (d->native) {
> QString allExtensions;
> QStringList filters = mime2KdeFilter(mimeTypes, );
> @@ -336,6 +334,8 @@ void KFileDialog::setMimeFilter(const QStringList
,
> }
> d->native->filter = filters.join(QLatin1String("\n"));
> }
> +else
> +d->w->setMimeFilter(mimeTypes, defaultType);
> }
Presumably all the other functions that do not currently test d->native
should be made to do so.
Cheers,
Jonathan
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
