On Thu, Apr 25, 2019 at 11:36 AM Luigi Toscano <luigi.tosc...@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