easystroke fails to build on s390x with -march=z13 and newer (as introduced in Ubuntu 20.04) because of an unexpected interaction of C++ template and compiler optimizations. tl;dr: The code relies on compiler- and optimization-level dependent behavior and the relatively aggressive inlining parameters on s390x with -march=z13 expose these. Note that I can reproduce the build failures on x86_64 with equivalent gcc parameters --param max-inline-insns-auto=80 --param inline-min-speedup=2 (I did not try any other arch).
The build can be fixed by moving the definition of template member functions Stroke::save() and Stroke::load() into gesture.h. As a side-effect, that change unifies code style, since all other classes have their ::save() and ::load() definitions in header files, too.
I have prepared a patch to that avail and submitted a PR upstream (https://github.com/thjaeger/easystroke/pull/14). While the upstream repo appears inactive, "markdstjohn" has included the patch in his fork https://github.com/markdstjohn/easystroke
What is going wrong in detail:
In gesture.h, the template member functions Stroke::save and Stroke::load get called via the serialize() function generated by boost's macro BOOST_SERIALIZATION_SPLIT_MEMBER(). Since the definitions of save()/load() are only available in gesture.cc, the compiler may produce two versions of Stroke::serialize(): one with save()/load() inlined in gesture.o and one with calls to save()/load() in all other translation units that #include gesture.h but lack the definitions from gesture.cc. Since the compiler inlined Stroke::save() and Stroke::load(), it will not export them in gesture.o (which is legitimate, to my analysis, since the code only requests an export of Stroke::serialize). As a result, linking can fail, depending on the link order (i.e., when the linker picks a version of Stroke::serialize() that would call save()/load() instead of the version with these functions inlined).
Note that my patch in https:/