<div dir="ltr"><div>Well, it is just confusing to have one stand-out :)<br><br></div>mfg Tobias<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 September 2017 at 19:35, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El dimecres, 6 de setembre de 2017, a les 8:09:14 CEST, Tobias C. Berner va<br>
escriure:<br>
<span class="">> Hi there<br>
><br>
> blogilo did not seem to have bumped its so-version:<br>
>    libcomposereditorwebenginepriv<wbr>ate.so.5.6.0<br>
> whereas the rest is at 5.6.1<br>
<br>
</span>Is that a problem?<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> mfg Tobias<br>
><br>
> On 5 September 2017 at 16:07, Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>><br>
><br>
> wrote:<br>
> > Am Dienstag, 5. September 2017, 10:51:43 CEST schrieb Ben Cooksley:<br>
> > > Minuet fails because it does not use ECM, and is therefore not<br>
> > > building with ASAN enabled. Because ASAN is contagious and Frameworks<br>
> > > is built with ASAN enabled, Minuet fails to compile. A similar issue<br>
> > > impacts Marble (which is disabled on the FreeBSD CI as it causes<br>
> > > issues for the Dependency Build jobs which the whole system depends on<br>
> > > to function properly).<br>
> > ><br>
> > > There are only two fixes for this: 1) Using ECM in both of those<br>
> > > projects or 2) Fixing Frameworks/ECM to pass along the enablement of<br>
> > > ASAN to anything which uses Frameworks.<br>
> > ><br>
> > > This is not a compile time issue on Linux due to how ASAN works on<br>
> > > Linux (however the binaries produced won't be usable unless ASAN is<br>
> > > injected into the binary using LD_PRELOAD)<br>
> ><br>
> > There is a third fix option:<br>
> > Fixing ECM code to support the dynamic lib option with ASAN also with<br>
> > clang as<br>
> > compiler, instead of resulting in different behaviour  (gcc using -shared-<br>
> > libasan, clang not) which in the aftermath then prevents LD_PRELOAD<br>
> > injection<br>
> > from helping on freebsd.<br>
> ><br>
> > From <a href="https://github.com/google/sanitizers/wiki/AddressSanitizer" rel="noreferrer" target="_blank">https://github.com/google/<wbr>sanitizers/wiki/<wbr>AddressSanitizer</a><br>
> ><br>
> >     Q: When I link my shared library with -fsanitize=address, it fails due<br>
> ><br>
> > to<br>
> > some undefined ASan symbols (e.g. asan_init_v4)?<br>
> ><br>
> >     A: Most probably you link with -Wl,-z,defs or -Wl,--no-undefined.<br>
> >     These<br>
> ><br>
> > flags don't work with ASan unless you also use -shared-libasan (which is<br>
> > the<br>
> > default mode for GCC, but not for Clang).<br>
> ><br>
> > Right now <a href="https://cgit.kde.org/extra-cmake-modules.git/tree/modules/" rel="noreferrer" target="_blank">https://cgit.kde.org/extra-<wbr>cmake-modules.git/tree/<wbr>modules/</a><br>
> > ECMEnableSanitizers.cmake#n164 only tries to dump (half of) the<br>
> > conflicting<br>
> > linker flags in case of clang, where instead it should possibly see to add<br>
> > the<br>
> > flag -shared-libasan. Though that might mean some juggling with supported<br>
> > clang versions, which made me stay away from trying to propose a fix<br>
> > (besides<br>
> > not having that much clue about ASan and clang :) ).<br>
> ><br>
> > Cheers<br>
> > Friedrich<br>
<br>
<br>
</div></div></blockquote></div><br></div>