On Sat, Jan 4, 2020 at 11:40 PM Albert Astals Cid <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > 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? 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 > > > > > <[email protected]> έγραψε: > > > > >> > > > > >> On Thu, Jan 2, 2020 at 7:25 AM Michail Vourlakos > > > > >> <[email protected]> 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 > > > > >> > <[email protected]> έγραψε: > > > > >> >> > > > > >> >> 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 > > > > > > > > > > > > > > > > > > > > > >
