MacOS Builds - KArchive & KDocTools

[Ben Cooksley]

On Thu, Apr 25, 2019 at 11:36 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> Ben Cooksley ha scritto:
> > Hi all,
> >
> > While getting Mac builds back on their feet this morning we've run
> > into a rather terminal build failure issue, centering around KArchive
> > and KDocTools.
> >
> > The issue is struck during the build of KDocTools, when the linking of
> > libKF5DocTools.dylib fails with the following message:
> >
> > Undefined symbols for architecture x86_64:
> >     "KFilterDev::KFilterDev(QString const&)", referenced from:
> >          KDocTools::saveToCache(QString const&, QString const&) in xslt_kde.cpp.o
> >      "KCompressionDevice::open(QFlags<QIODevice::OpenModeFlag>)",
> > referenced from:
> >          KDocTools::saveToCache(QString const&, QString const&) in xslt_kde.cpp.o
> >      "KCompressionDevice::close()", referenced from:
> >          KDocTools::saveToCache(QString const&, QString const&) in xslt_kde.cpp.o
> >      "KCompressionDevice::~KCompressionDevice()", referenced from:
> >          KDocTools::saveToCache(QString const&, QString const&) in xslt_kde.cpp.o
> >    ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see invocation)
> >
> > Anyone got any ideas?
> >
>
> It was reported as https://bugs.kde.org/show_bug.cgi?id=406663 less than one
> week ago, but to be honest I have no idea. Is it a new issue, or have the
> failure started recently?
> The only relevant change to KFilterDev is:
> https://commits.kde.org/karchive/710ffdc3c45a1c683ccca988138798f9945c26b1
> The code of KDocTools has been pretty stable for a while.

The failure only started recently, however that's a little bit of a
red herring because the Binary Factory doesn't regularly do rebuilds
of things, so the last time this would have been validated as working
would have been the last Frameworks release.

Not helping things is that we recently upgraded the Binary Factory
node from MacOS Sierra to Mojave, and then updated XCode, so this
could be more due to those changing rather than things changing on the
KDE side.

Having a look with 'nm' makes it looks like this is a symbol
visibility/export issue in KArchive:

KDEs-Mac-mini:macos-64-clang kdeosxci$ nm -demangle
lib/libKF5Archive.dylib  | grep -i KFilterDev
000000000002ab70 s qt_meta_data_KFilterDev
000000000002c818 d qt_meta_stringdata_KFilterDev
0000000000028800 t KFilterDev::qt_metacall(QMetaObject::Call, int, void**)
00000000000287a0 t KFilterDev::qt_metacast(char const*)
000000000002c140 s KFilterDev::staticMetaObject
0000000000028770 t KFilterDev::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**)
000000000000c550 t KFilterDev::compressionTypeForMimeType(QString const&)
000000000000c540 t KFilterDev::KFilterDev(QString const&)
000000000000c480 t KFilterDev::KFilterDev(QString const&)
00000000000288a0 t KFilterDev::~KFilterDev()
0000000000028890 t KFilterDev::~KFilterDev()
0000000000028780 t KFilterDev::metaObject() const
000000000002c3a0 s typeinfo for KFilterDev
000000000002ac05 s typeinfo name for KFilterDev
000000000002c2a8 s vtable for KFilterDev
000000000002c4f0 d KFilterDev::compressionTypeForMimeType(QString
const&)::$_0::operator()() const::qstring_literal
000000000002c530 d KFilterDev::compressionTypeForMimeType(QString
const&)::$_1::operator()() const::qstring_literal
000000000002c570 d KFilterDev::compressionTypeForMimeType(QString
const&)::$_2::operator()() const::qstring_literal
000000000002c5b0 d KFilterDev::compressionTypeForMimeType(QString
const&)::$_3::operator()() const::qstring_literal

Does this seem consistent?

(Running nm -g doesn't include any of the KFilterDev classes)

>
> Ciao
> --
> Luigi

Cheers,
Ben