KDE Applications 17.08.1 packages available for packagers

[Friedrich W. H. Kossebau]

Am Dienstag, 5. September 2017, 10:51:43 CEST schrieb Ben Cooksley:
> Minuet fails because it does not use ECM, and is therefore not
> building with ASAN enabled. Because ASAN is contagious and Frameworks
> is built with ASAN enabled, Minuet fails to compile. A similar issue
> impacts Marble (which is disabled on the FreeBSD CI as it causes
> issues for the Dependency Build jobs which the whole system depends on
> to function properly).
> 
> There are only two fixes for this: 1) Using ECM in both of those
> projects or 2) Fixing Frameworks/ECM to pass along the enablement of
> ASAN to anything which uses Frameworks.
> 
> This is not a compile time issue on Linux due to how ASAN works on
> Linux (however the binaries produced won't be usable unless ASAN is
> injected into the binary using LD_PRELOAD)

There is a third fix option:
Fixing ECM code to support the dynamic lib option with ASAN also with clang as 
compiler, instead of resulting in different behaviour  (gcc using -shared-
libasan, clang not) which in the aftermath then prevents LD_PRELOAD injection 
from helping on freebsd.

>From https://github.com/google/sanitizers/wiki/AddressSanitizer
    Q: When I link my shared library with -fsanitize=address, it fails due to 
some undefined ASan symbols (e.g. asan_init_v4)?

    A: Most probably you link with -Wl,-z,defs or -Wl,--no-undefined. These 
flags don't work with ASan unless you also use -shared-libasan (which is the 
default mode for GCC, but not for Clang).

Right now https://cgit.kde.org/extra-cmake-modules.git/tree/modules/
ECMEnableSanitizers.cmake#n164 only tries to dump (half of) the conflicting 
linker flags in case of clang, where instead it should possibly see to add the 
flag -shared-libasan. Though that might mean some juggling with supported 
clang versions, which made me stay away from trying to propose a fix (besides 
not having that much clue about ASan and clang :) ).

Cheers
Friedrich