El dissabte, 4 de gener de 2020, a les 19:26:02 CET, Ben Cooksley va escriure: > On Sat, Jan 4, 2020 at 11:40 PM Albert Astals Cid <aa...@kde.org> wrote: > > > > El dissabte, 4 de gener de 2020, a les 8:02:54 CET, Ben Cooksley va > > escriure: > > > On Sat, Jan 4, 2020 at 10:54 AM Albert Astals Cid <aa...@kde.org> wrote: > > > > > > > > El divendres, 3 de gener de 2020, a les 10:01:50 CET, Ben Cooksley va > > > > escriure: > > > > > On Thu, Jan 2, 2020 at 9:39 AM Michail Vourlakos > > > > > <mvourla...@gmail.com> wrote: > > > > > > > > > > > > https://phabricator.kde.org/source/latte-dock/browse/master/app/FakeTarget.cmake > > > > > > > > > > > > Can you please make a PR because I am not that sure I understand > > > > > > what I need to change in it > > > > > > > > > > Sorry, CMake is a bit beyond me in this case. > > > > > We would be wanting to change line 16 in this case, to see if > > > > > ECM_ENABLE_SANITIZERS is empty (because if it isn't, we shouldn't be > > > > > running qmllint). > > > > > > > > > > Does anyone on the development list know of the best way to tackle > > > > > this? > > > > > > > > > > (Background to this: qmllint is a application shipped with Qt, and > > > > > thus not built with ASAN, but our libraries are built with ASAN so > > > > > trying to run qmllint on the CI system will always fail. You can > > > > > workaround this on Linux by forcibly injecting ASAN into the process > > > > > using LD_PRELOAD but ASAN is statically linked on FreeBSD, so it is > > > > > impossible to workaround there) > > > > > > > > You mean there's no dynamic library ASAN at all in FreeBSD? > > > > > > That is correct, ASAN is statically linked on FreeBSD. > > > > Just being very verborse here, the fact that the library is statically > > linked when compiling doesn't mean that a dynamic version can not also > > exist, i.e. on my system i have both libz.a and libz.so > > Yes. The dynamic version does not exist at all to my knowledge on FreeBSD. > > > > > > I'm not sure if that is because of the way they've decided to package > > > ASAN, or if it because that is the way that Clang does it. > > > > > > I'm inclined to think it is Clang, because even on Linux/GCC if you > > > try to run an executable that isn't linked to ASAN, but which does use > > > a library that is linked to ASAN, then it will abort on you with a > > > message about ASAN needing to be loaded first (before anything else is > > > loaded) > > > > > > That is why Kirigami and Marble have the "force-inject-asan" flag set > > > in their Build Specifications on the CI system to make their tests > > > pass - because Kirigami reiies on tools shipped with Qt itself (and we > > > use distribution Qt), and Marble doesn't use ECM (so the necessary > > > flags never get passed to the compiler - Marble also doesn't build on > > > FreeBSD due to this). > > > > If we have confirmed with the FreeBSD people that there's no way to get a > > libasan.so we can inject with LD_PRELOAD I only see two options: > > * Build Qt with ASAN > > * Don't build anything with ASAN in FreeBSD > > Not sure what the line of thinking is here?
The line of thinking was "we can't [always] make it work, so don't do it". I know it works in 99.99% of the cases but if it doesn't work in 0.01% it means it doesn't work at all, no? Cheers, Albert > > Apart from those two exceptions, KDE projects aren't affected by this > as they don't rely on Qt executables that load KDE libraries - the > only time this really happens is with some QML stuff (which is why > Kirigami is affected). Marble is simply an abberation as it does not > use ECM yet does use KDE libraries. > > The rest all use ECM, and are thus built with ASAN enabled, which > ensures that they not only build successfully, but are also able to be > executed successfully at runtime (a situation we cannot guarantee on > Linux - hence why Kirigami/Marble need the forced injection) > > The only thing having a libasan.so would give us is passing tests for > Kirigami. > > > > > The first may be a huge can of worms though since maybe we need to build > > other stuff that Qt depends on with ASAN, so i guess option two is the > > solution? > > > > It wouldn't be very terrible since AFAIK we don't have many "FreeBSD only" > > code, or do we? > > > > Cheers, > > Albert > > > > Cheers, > Ben > > > > > > > We don't set that flag globally because Skrooge relies on Java for > > > some of it's unit tests, and Java really does not like ASAN being > > > injected into it (it crashes). > > > > > > > > > > > Cheers, > > > > Albert > > > > > > Cheers, > > > Ben > > > > > > > > > > > > > > > > > Cheers, > > > > > Ben > > > > > > > > > > > > > > > > > Στις Τετ, 1 Ιαν 2020, 10:30 μ.μ. ο χρήστης Ben Cooksley > > > > > > <bcooks...@kde.org> έγραψε: > > > > > >> > > > > > >> On Thu, Jan 2, 2020 at 7:25 AM Michail Vourlakos > > > > > >> <mvourla...@gmail.com> wrote: > > > > > >> > > > > > > >> > found in the Internet that the CMake command should contain: > > > > > >> > > > > > > >> > > > > > > >> > cmake ........... -DCMAKE_BUILD_TYPE=Release > > > > > >> > > > > > > >> > > > > > >> Because we are running a CI system, and therefore want tests with > > > > > >> full > > > > > >> asserts enabled, we use a build type of Debug. > > > > > >> I haven't seen the qmllint failures elsewhere, mind linking me to > > > > > >> where to find app/FakeTarget.cmake? > > > > > >> > > > > > >> If it is part of Latte Dock, you'll need to change it to skip > > > > > >> qmllint > > > > > >> when ASAN support is enabled (which is controlled by > > > > > >> -DECM_ENABLE_SANITIZERS being passed to CMake) > > > > > >> > > > > > >> Cheers, > > > > > >> Ben > > > > > >> > > > > > >> > > > > > > >> > Στις Τετ, 1 Ιαν 2020 στις 8:16 μ.μ., ο/η Ben Cooksley > > > > > >> > <bcooks...@kde.org> έγραψε: > > > > > >> >> > > > > > >> >> Hi Michail, > > > > > >> >> > > > > > >> >> A while back when we upgraded things on FreeBSD, one of the > > > > > >> >> unfortunate casualties of this process was the Latte Dock > > > > > >> >> builds on > > > > > >> >> that platform, which now fail with a ASAN related error. > > > > > >> >> > > > > > >> >> (See > > > > > >> >> https://build.kde.org/job/Extragear/job/latte-dock/job/stable-kf5-qt5%20FreeBSDQt5.13/99/console) > > > > > >> >> > > > > > >> >> Examining the build log, I note that it looks like you are > > > > > >> >> running > > > > > >> >> `qmllint` as part of the final steps before linking the > > > > > >> >> executable. > > > > > >> >> > > > > > >> >> Could you confirm whether this is the case? > > > > > >> >> > > > > > >> >> Cheers, > > > > > >> >> Ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
