libkdegames doesn't build yet, due to some changes in build procedures apparently; there is a ticket, and hopefully there will shortly be a proper fix. Having said that, with a jury-rigged way around that (not correct, but it works), all the KDE4 games would build. But they have display issues. A non KDE app (MacVim) also has those, possibly due to changes in how a legacy rendering API worked; apparently it was more tolerant of incremental window updates than it is now.
https://github.com/macvim-dev/macvim/issues/751 I have no idea if it's really the same underlying cause to the KDE4 graphics issues vs MacVim, but they both are not handling display updating correctly from the looks of it. > On Oct 10, 2018, at 23:44, Ian Wadham <iandw...@gmail.com> wrote: > > Hi René, > > Long time no see. > >> On 11 Oct 2018, at 5:10 am, René J.V. Bertin <rjvber...@gmail.com> 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. > > > > > > >
