KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?
Albert Astals Cid
aacid at kde.org
Mon Apr 25 22:26:45 BST 2016
El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H. Kossebau
> can anyone shed full light on KDE CI and the usage of ASan?
> Currently e.g. all tests of Marble are failing, with the message
> "ASan runtime does not come first in initial library list; you should either
> link runtime to your application or manually preload it with LD_PRELOAD."
> As Marble tries to be optionally Qt-only by tradition, also the current
> Qt5(/ KF5)-based version has lots of custom CMake logic, for full
> independence, and only falls back to using ECM macros/settings when it
> comes to Plasma & other KDE system integration code.
> Which currently also means all tests are not influenced anywhere by ECM
> macros. Incl. KDECompilerSettings.cmake (and thus
> ECMEnableSanitizers.cmake). So the code from ECMEnableSanitizers.cmake
> which handles the
> "ECM_ENABLE_SANITIZERS" cmake argument is never run.
> Where currently -DECM_ENABLE_SANITIZERS='address' seems to be passed in the
> kf5-qt5 configuration:
> Is this the reason that all the Marble tests fail on KDE CI, with the given
> So do any projects which are build on KDE CI need to have
> ECMEnableSanitizers.cmake included?
> Would it make sense to have ASan as an option to be turned off?
It's compile time, it's off for your project, but you're linking against KF5
libraries that have ASAN compiled in.
> And is that possible, or is ASan usage viral (if deps built on CI have it,
> it needs to be used)?
Yes ASan usage is viral-ish, if you're using a library that was compiled with
ASAN you either need to compile your binary with asan too or pass the
LD_PRELOAD as the error says, that may be tricky since it needs a full path.
> While using ASan seems to be useful for improved test coverage, this
> requirement still would need to be explained and documented somewhere,
Where would you document it?
More information about the kde-core-devel