Hi René, Long time no see.
> On 11 Oct 2018, at 5:10 am, René J.V. Bertin <[email protected]> wrote: > I'm trying to figure out why port:kde4-workspace fails to build on 10.14, > with linker errors that suggest that the system clang has a subtle new and > incompatible symbol visibility policy. > (https://trac.macports.org/ticket/57332). > > Are there known issues with Qt4 and/or KDE4 software on Apple's latest and > greatest (desert environment O:^))? > > R. I am on 10.13.6 High Sierra and have no plans to move to Mojave. However, I have Xcode !0.0 (10A255) and several recent updates to Command Line Tools which were hitting my system almost daily just before the Mojave release date (c. 24 Sept?). I believe those versions of Xcode and CLT are “Mojave ready” and may have some of the problems you and others are experiencing in Mojave. At the time (3rd week in September) I was attempting to upgrade my former MacBook Pro (early 2011) from Lion to High Sierra in order to give it to my son. The word from Apple (then) was to first upgrade from Lion to El Capitan and then upgrade to High Sierra. There were numerous problems in this process, necessitating about 3 hours on the ‘phone to Apple Support, who were very helpful. I think the problems were mainly due to changes in security policies at the App Store and in Apple Accounts since Lion, but also the replacement of Apple app iPhoto by an iOS-like Photos app, which threw up some errors. All that need not concern us here, but I did notice some graphics glitches and other weird happenings in the resultant High Sierra desktop, unrelated to KDE 4. I wonder if there is some problem in Apple’s upgrade path from older systems to Xcode 10.0 and High Sierra or Mojave… I decided to stop struggling with the upgraded system. I saved offline all the files I wanted to keep, then followed Apple’s recommended procedure for handing over ownership of an old machine (Apple’s only supported procedure for that?) — i.e. I wiped and re-formatted my old machine’s hard disk and installed High Sierra “from scratch”, using my son’s Apple Account and login ID. The resulting system worked fine and my son is delighted with it. Re KDE 4, I believe the source code used in MacPorts is from the KDE 4.14.3 release in November 2014, the last “official" release of KDE 4 libraries and apps. However, there were some releases of KDE 4 apps (and maybe some libraries) in the “Applications” series of releases. See https://community.kde.org/Schedules. At some point, when the porting of KDE apps to KF5 was complete, the “Applications” releases stopped accepting KDE 4 code, but I forget exactly when that was. Certainly I was able to release new features in some of my KDE Games in 2015, using KDE 4 libraries (notably the Palapeli and KSudoku games). Others have helpfully ported those games to KF5, but I myself have never been able to get KF5 and Qt5 built and working on my Apple machine. Re your build problem, I now find I cannot build KDE 4 Palapeli code with High Sierra and Xcode 10.0 and its CLT, using my local source repositories, which contain updates that are in the KDE central origin/master but after KDE 4.14.3. There are three classes of problem: one fatal and two in the warnings category. One of the warnings is a whole lot of messages of the form: ld: warning: text-based stub file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd and library file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices are out of sync. Falling back to library file for linking. I googled this and apparently a *.tbd file is a cache for symbols in a corresponding library and gets out of synch with its library. The cache is supposed to speed up Xcode operations. Trivial as the problem may be, it suggests that there may be other problems in Apple’s migration paths from one OS X version to another. The second type of warning is to do with KDE code that uses the words “struct” and “class” interchangeably for the same body of data and methods. Clang has been complaining about this for several years, but it has never caused build problems. Example: /kdedev/games/palapeli/libpala/slicerproperty.cpp:25:1: warning: 'Private' defined as a struct here but previously declared as a class [-Wmismatched-tags] struct Pala::SlicerProperty::Private ^ /kdedev/games/palapeli/libpala/slicerproperty.h:86:4: note: did you mean struct here? class Private; ^~~~~ struct There are loads of warnings like the above in the Palapeli compile. Finally the build of Palapeli fails because of undefined symbols. Curiously, the missing symbols seem to relate to the areas of code where the (non-fatal) struct/class ambiguities occur. Is this a pattern or a coincidence? I have not tried it with MacPorts’ snapshot of code for Palapeli, but maybe the same problem would occur. Undefined symbols for architecture x86_64: …………………………………. "Pala::SlicerProperty::setChoices(QList<QVariant> const&)", referenced from: GoldbergSlicer::GoldbergSlicer(QObject*, QList<QVariant> const&) in slicer-goldberg.o "Pala::SlicerProperty::setEnabled(bool)", referenced from: GoldbergSlicer::GoldbergSlicer(QObject*, QList<QVariant> const&) in slicer-goldberg.o "Pala::SlicerProperty::setDefaultValue(QVariant const&)", referenced from: GoldbergSlicer::GoldbergSlicer(QObject*, QList<QVariant> const&) in slicer-goldberg.o I have not investigated further, nor do I plan to. I feel I am too old for coding nitty-gritty now and am spending my remaining days painting pictures. Time to get back to that. There is a show coming up…:-) I hope some of the above may be relevant. I have not tried building Palapeli from source in MacPorts, but maybe the same problem would occur. All the best, Ian W.
