Android SDK images to Qt 5.12
Ben Cooksley
bcooksley at kde.org
Fri Feb 22 05:35:06 GMT 2019
On Fri, Feb 22, 2019 at 8:46 AM Volker Krause <vkrause at kde.org> wrote:
>
> On Saturday, 16 February 2019 19:45:03 CET Aleix Pol wrote:
> > El ds., 16 de febr. 2019, 19:42, Ben Cooksley <bcooksley at kde.org> va
> >
> > escriure:
> > > On Sat, Feb 16, 2019 at 11:17 PM Volker Krause <vkrause at kde.org> wrote:
> > > > On Thursday, 14 February 2019 09:09:57 CET Volker Krause wrote:
> > > > > On Wednesday, 13 February 2019 16:28:20 CET Aleix Pol wrote:
> > > > > > Hey,
> > > > > > By popular demand, I updated our CI tooling to use the new images.
> > >
> > > Many of
> > >
> > > > > > you already tried them.
> > >
> > > > > > It's building now as of:
> > > https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt
> > >
> > > > > > 5. 12%20SDK
> > > > > >
> > > > > > This means that we'll be changing compilers to clang too.
> > > > > >
> > > > > > Some builds may fail, help will be welcome. ;)
> > > > >
> > > > > Thanks a lot! Some of that breakage is caused by my changes, but at
> > >
> > > least I
> > >
> > > > > can see it now again :) Will look into that ASAP.
> > > >
> > > > Fixes for Konversation and KStars have been pushed too now, which leaves
> > > > Marble and VVave. Those two seem to have issues unrelated to the image
> > >
> > > change,
> > >
> > > > and for the last time built successfully several months ago if I read
> > >
> > > this
> > >
> > > > correctly. So I think we finally have this all back under control :)
> > >
> > > Given these two appear to be terminally broken, should we go ahead and
> > > disable them for now until their respective maintainers/developers
> > > have a chance to diagnose and fix the issue?
> > >
> > > > Thanks,
> > > > Volker
> > >
> > > Cheers,
> > > Ben
> >
> > I talked with Camilo and he said he'd look into vvave build. Marble it's
> > probably something we should look into rather than nuke?
>
> Looked into this, it's caused by a combination of KDE_L10N_AUTO_TRANSLATIONS
> being enabled and a double inclusion of KDECMakeSettings.cmake, which
> duplicates the fetch-translation magic. With any of those gone it builds fine.
>
> That sounds easy to fix, however their build system seems to have ECM as an
> optional dependency (sic), which makes this rather messy.
This optional nature of ECM causes other issues as well so this is
something that should either:
a) Be changed to make it non-optional
b) Result in Marble being removed from Android builds
The other issues for those wondering are around ASAN. For the CI
system we enable this globally for all builds - but having this work
relies on ECM being used by a project. If a project doesn't use ECM,
then it doesn't enable the necessary ASAN flags, which leads to either
broken binaries (on Linux) or totally broken builds (on FreeBSD)
because ASAN is highly contagious (if one of your dependencies uses
it, you're forced to use it yourself)
On Linux we can workaround these issues by forcibly injecting (through
LD_PRELOAD) the ASAN libraries into the test run process (which is a
bit annoying, but we have to do it for other projects like those that
use Qt's QML executor as part of their tests anyway so it's no big
deal)
For FreeBSD however it's fatal and causes builds to fail outright, as
the produced binaries don't have the necessary ASAN symbols present.
This occurs because ASAN isn't a separate dynamic library on FreeBSD -
it's something that gets baked into the final binary as a statically
linked library. As a consequence when it goes to link Frameworks in
(which are used by Marble strangely enough even though it doesn't use
ECM) the build blows up. This in turn broke the builds of projects
that depended on Marble (which is why Marble is blacklisted on FreeBSD
on the CI system) because we could never successfully build Marble,
and thus were unable to provide the dependency when it was requested
by the project's dependency metadata.
>
> Regards,
> Volker
Cheers,
Ben
More information about the KDE-Android
mailing list