El dimecres, 27 d’abril de 2016, a les 0:25:30 CEST, Friedrich W. H. Kossebau va escriure: > Am Dienstag, 26. April 2016, 23:21:40 CEST schrieb Albert Astals Cid: > > El dimarts, 26 d’abril de 2016, a les 18:50:55 CEST, Friedrich W. H. > > Kossebau > > > > va escriure: > > > 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: > <snip> > > > > > > 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. > > > > You set it to the asan library before running your binary. > > Okay, that sounds doable. "Just" needs someone to add support for that :) > Filed a feature request on phabricator for that, anyone interested to earn > some laurels on that? > https://phabricator.kde.org/T2366 > > > > 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. > > > > It's hard to avoid unless you compile all libraries twice both with and > > without ASAN. > > Double builds ideally can be avoided. And after all ASAN is very much useful > on CI, that's why you(?) pushed it there, for some good catches already > (myself could also harvest some bugs from it already) :) > > > It is not a requirement for "any projects on KDE CI". > > > > As pointed you can just LD_PRELOAD the ASAN library if you have troubles. > > Also that is only needed if you use other projects that are linked against > > ASAN. > > As I understood it so far, almost anything built on KDE CI is built with > ASAN, incl. 3rd-party dependencies like Qt5, no?
"only" the kf5-qt5 jobs that use cmake get built with ASAN > As said above, it only > makes sense to me to do it. But we need to also have support for the > non-ECM-using projects, that's what I am here for and try to understand how > things are done, to see what could be done. > > > That is, you're trying not to use ECM (or ECMEnableSanitizers.cmake) but > > you depend on KF5 stuff that depends on ECM/ECMEnableSanitizers.cmake, > > maybe you're trying to be too fine in not needing ECM. > > While I personally would also see to use ECM & CMake where possible, we > still need to consider at least: > > a) KF5 products do not require CMake as the buildsystem for any of its > consumers. There is extra dance for supporting qmake/pkg-config buildsystems > at least. So other potential KDE projects which use KF5 but not CMake > cannot use ECM. Ideally there would be similar helpers like > ECMEnableSanitizers.cmake one day for them, sure, but those still would be > extra dependencies, and any extra dependency increases burdens, so would be > nice to have it special settings for KDE CI optional if possible without a > big deal. > > b) Qt5 on CI is also build with ASAN (AFAIK, that is why the all Marble > tests, which are Qt5-only, are failing, unless I missed something). No, Qt5 is not built with ASAN on CI. It is strange that your Qt5-only tests are failing, may it be that they are loading some plugin that is linked against some KF5 lib? > So > Qt5-only projects (as in: ECM/KF5-less) still would need to have separate > support by/ for the KDE CI. Qt5 projects that don't use ECM nor KF5 should be fine. Cheers, Albert > > Cheers > Friedrich