KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

Friedrich W. H. Kossebau kossebau at kde.org
Tue Apr 26 17:50:55 BST 2016


Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Hi,
> > 
> > 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."
> > 
> > https://build.kde.org/job/marble%20master%20kf5-qt5/
> > PLATFORM=Linux,compiler=gcc/26/testReport/
> > 
> > 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:
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git&a=blob&f=build
> > %2Fkf5-qt5.cfg
> > 
> > Is this the reason that all the Marble tests fail on KDE CI, with the
> > given
> > error?
> > 
> > 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.

Given we have stable setting on CI, the path might be known perhaps.

What needs to be done with LD_PRELOAD here exactly? Perhaps that could be done 
optionally based on a flag in the build setup in the future.

Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based 
buildsystem) for any projects on KDE CI to have tests being run properly (if 
using other KDE CI products) feels like a small obstacle.
If possible without too much pain, it might be nice to avoid that.

(For Marble nevertheless I have a patch up for review to optionally use 
ECMEnableSanitizers.cmake)

Cheers
Friedrich




More information about the kde-core-devel mailing list