kde4-workspace fails to build with Xcode 10

[cs0rfecs0rfe (Ian Ferguson)]

Attempting a clean install of kde4-workspace fails to build:

:info:build Undefined symbols for architecture x86_64:
:info:build   "ScreenPreviewWidget::setPreview(Plasma::Wallpaper*)", referenced from:
:info:build       BackgroundDialog::changeBackgroundMode(int) in backgrounddialog.cpp.o
:info:build   "ScreenPreviewWidget::setRatio(double)", referenced from:
:info:build       BackgroundDialog::BackgroundDialog(QSize const&, Plasma::Containment*, Plasma::View*, QWidget*, QString const&, KConfigSkeleton*) in backgrounddialog.cpp.o
:info:build   "ScreenPreviewWidget::ScreenPreviewWidget(QWidget*)", referenced from:
:info:build       BackgroundDialog::BackgroundDialog(QSize const&, Plasma::Containment*, Plasma::View*, QWidget*, QString const&, KConfigSkeleton*) in backgrounddialog.cpp.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)

Is the appropriate (screenpreviewwidget) library missing from the list passed to the linker?

[cs0rfecs0rfe (Ian Ferguson)]

Log file referred to by the top level error message.

[mf2k (Frank Schima)]

In the future, please add the port maintainer(s) to Cc (port info --maintainers kde4-workspace), if any.

[RJVB (René Bertin)]

Those symbols are provided through libkworkspace, and as far as I can see that library is generated and included on the failing link command.

Has anything changed in 10.14 w.r.t. the default symbol visibility?

[cs0rfecs0rfe (Ian Ferguson)]

Replying to mf2k:

In the future, please add the port maintainer(s) to Cc (port info --maintainers kde4-workspace), if any.

Apologies, I will do. That's the first time I've raised a ticket. - Ian

[RJVB (René Bertin)]

port dir diff

[RJVB (René Bertin)]

Can you please apply the attached patch to the port dir

> (cd `port dir kde4-workspace`/../.. ; patch -Np1 -i /path/to/kde4-workspace.diff)

and then retry the build after doing port clean kde4-workspace?

The patch bumps the port to the latest version and drops the build of all plasma components. Those were never quite useful and omitting their build may just work around the problem if (as I hope) it was in fact the only manifestation of whatever breaks the build on 10.14 .

The patch also adds -k to the build options, so if more errors are laying in wait we should get them all at once.

[cs0rfecs0rfe (Ian Ferguson)]

Working on it now.......

Replying to RJVB:

Can you please apply the attached patch to the port dir

> (cd `port dir kde4-workspace`/../.. ; patch -Np1 -i /path/to/kde4-workspace.diff)

and then retry the build after doing port clean kde4-workspace?

The patch bumps the port to the latest version and drops the build of all plasma components. Those were never quite useful and omitting their build may just work around the problem if (as I hope) it was in fact the only manifestation of whatever breaks the build on 10.14 .

The patch also adds -k to the build options, so if more errors are laying in wait we should get them all at once.

[cs0rfecs0rfe (Ian Ferguson)]

main.log after rebuild following patch.

[cs0rfecs0rfe (Ian Ferguson)]

Replying to RJVB:

Can you please apply the attached patch to the port dir

> (cd `port dir kde4-workspace`/../.. ; patch -Np1 -i /path/to/kde4-workspace.diff)

and then retry the build after doing port clean kde4-workspace?

The patch bumps the port to the latest version and drops the build of all plasma components. Those were never quite useful and omitting their build may just work around the problem if (as I hope) it was in fact the only manifestation of whatever breaks the build on 10.14 .

The patch also adds -k to the build options, so if more errors are laying in wait we should get them all at once.

Hi RJVB,

I applied the patch which resulted in the following output:

patching file kde/kde4-workspace/Portfile
Reversed (or previously applied) patch detected!  Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file kde/kde4-workspace/Portfile.rej
The next patch would delete the file kde/kde4-workspace/files/no-oxygen-theme.patch,
which does not exist!  Skipping patch.
1 out of 1 hunk ignored
patching file kde/kde4-workspace/files/patch-CMakeLists-for-OSX.patch
Reversed (or previously applied) patch detected!  Skipping patch.
7 out of 7 hunks ignored -- saving rejects to file kde/kde4-workspace/files/patch-CMakeLists-for-OSX.patch.rej
The next patch would create the file kde/kde4-workspace/files/patch-input-wheelzooms.diff,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file kde/kde4-workspace/files/patch-input-wheelzooms.diff.rej
The next patch would delete the file kde/kde4-workspace/files/patch-libs-CMakeLists.patch,
which does not exist!  Skipping patch.
1 out of 1 hunk ignored

I then rebuilt (sudo port install kde4-workspace) which resulted in the attached log file.

Have I done this correctly? Was 'port install' the right thing to do or should I have used some other command to rebuild without downloading? Please excuse the dumb questions - I'm a recent immigrant to Mac/Macports from Linux and I'm still finding my way around.

[RJVB (René Bertin)]

Erm, from what tree did you get the port, i.e. what does port dir kde4-workspace print? Or did you maybe apply the patch twice, the errors above suggest that? Actually, that's the only scenario where these exact errors would make sense.

Either way you're now getting a lot further but there are 3 or 4 other and highly similar errors. Which I cannot reproduce, and which don't seem to make sense.

The errors about missing typeinfo and vtable do ring a bell; I've seen that happen in Qt5 code (under QMake control) because of a missing moc file, but in KDE software (which is under CMake control) that should give a missing file error much earlier during the build.

The only thing I can suggest at this point is to clean the build again and try with the same compiler I have been able to test with: clang 5.0 from MacPorts. At least we can then exclude the possibility that the system clang has introduced some subtle incompatibility. For that, do sudo port -s install kde4-workspace configure.compiler=macports-clang-5.0 . BTW, if you don't plan to use the oxygen style you can speed up things a bit (and get rid of 1 error) by disabling the style; add -oxygen just after the port name. If you're handy with a text editor and cli-fu I can give some instructions how to skip the git checkout step which takes a couple of minutes (for me).

BTW, did you already install other KDE4 ports? The kde4-workspace port is of interest only (on Mac) if you want to be able to configure a small selection of KDE configurable things (incl. icon theme, fonts, widget style) without editing the configuration files by hand. It does not provide a full plasma desktop, that's not possible on Mac.

[cs0rfecs0rfe (Ian Ferguson)]

Replying to RJVB:

Erm, from what tree did you get the port, i.e. what does port dir kde4-workspace print? Or did you maybe apply the patch twice, the errors above suggest that? Actually, that's the only scenario where these exact errors would make sense.

Either way you're now getting a lot further but there are 3 or 4 other and highly similar errors. Which I cannot reproduce, and which don't seem to make sense.

The errors about missing typeinfo and vtable do ring a bell; I've seen that happen in Qt5 code (under QMake control) because of a missing moc file, but in KDE software (which is under CMake control) that should give a missing file error much earlier during the build.

The only thing I can suggest at this point is to clean the build again and try with the same compiler I have been able to test with: clang 5.0 from MacPorts. At least we can then exclude the possibility that the system clang has introduced some subtle incompatibility. For that, do sudo port -s install kde4-workspace configure.compiler=macports-clang-5.0 . BTW, if you don't plan to use the oxygen style you can speed up things a bit (and get rid of 1 error) by disabling the style; add -oxygen just after the port name. If you're handy with a text editor and cli-fu I can give some instructions how to skip the git checkout step which takes a couple of minutes (for me).

BTW, did you already install other KDE4 ports? The kde4-workspace port is of interest only (on Mac) if you want to be able to configure a small selection of KDE configurable things (incl. icon theme, fonts, widget style) without editing the configuration files by hand. It does not provide a full plasma desktop, that's not possible on Mac.

Many thanks for rapid and detailed response.

a) Yes, it's possible I applied the patch twice - sorry about that. For what it's worth, port dir kde4-workspace returns:

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/kde/kde4-workspace

b) I'll have a go with clang and report back

c) Yes, I'm cli/text-editor compliant!

d) I've installed several of the KDE ports - (I'm really interested in okteta, konsole, kwrite and konqueror) but I have problem with them (a bad 'flashing' when they seem to refresh some of their window components out of sync). In order to try and fix that I *think* I need to set the 'look and feel' (?) to qtcurve. I'd assumed I need systemsettings (which is part of kde-workspace) to do that, but I guess from what you say there must be a configuration file somewhere I could edit. If I can get systemsettings sorted I'll raise another ticket for the 'flashing widgets' problem.

[cs0rfecs0rfe (Ian Ferguson)]

Attempted build with:

sudo port clean kde4-workspace
sudo port -s install kde4-workspace -oxygen configure.compiler=macports-clang-5.0

This too fails - the resulting log is main.log.3 (attached).

[RJVB (René Bertin)]

Does QtCurve build OK? The port comes with a few theme files, and includes a basic kdeglobals file for the GTk2 theme which you can use as a starting point. It also has a stylerc file for the style style (installed as /opt/local/etc/xdg/qtcurve/stylerc). I can't remember now if the Qt4 style uses that file, but you can copy it to ~/.config/qtcurve/stylerc. It's tuned to fit in as well as possible with the native Mac look.

You say you come from Linux, so the obvious alternative (which I also used in the beginning!) would be to prepare and then take your ~/.kde/share/config/kdeglobals file from there and then edit it to refer to the proper paths. On Mac it will probably have to live in ~/Library/Preferences/KDE/share/config, btw.

Note however that I won't be able to do anything about the flashing you mention (if it's anything other than the known glitches which can be avoided by using QtCurve). But you can experiment with --graphicssystem opengl or by setting the RasterOff environment variable.

[RJVB (René Bertin)]

A thought: could you see if you have the 10.13 SDK installed in XCode, and install it if not? XCode itself may have a UI for that in its preferences dialog, if not they're here:

​https://github.com/phracker/MacOSX-SDKs

Then edit the portfile (port edit kde4-workspace) and somewhere appropriate put the following

set macosx_deployment_target 10.13
configure.sdkroot /path/to/MacOSX10.13.sdk

then, to speed up the process:

sudo rm -rf `port work kde4-workspace`/build
sudo vi `port work kde4-workspace`/.macports.kde4-workspace.state

From that statefile, remove the lines that say the configure step has been done. This basically "rewinds" the MacPorts install-from-source procedure.

If you're adventurous and feel like helping out you could iterate this, downgrading the SDK until the port installs...

EDIT: It doesn't seem that changing to clang 5 made any difference ... that's really weird!

[cs0rfecs0rfe (Ian Ferguson)]

Replying to RJVB:

Does QtCurve build OK? The port comes with a few theme files, and includes a basic kdeglobals file for the GTk2 theme which you can use as a starting point. It also has a stylerc file for the style style (installed as /opt/local/etc/xdg/qtcurve/stylerc). I can't remember now if the Qt4 style uses that file, but you can copy it to ~/.config/qtcurve/stylerc. It's tuned to fit in as well as possible with the native Mac look.

You say you come from Linux, so the obvious alternative (which I also used in the beginning!) would be to prepare and then take your ~/.kde/share/config/kdeglobals file from there and then edit it to refer to the proper paths. On Mac it will probably have to live in ~/Library/Preferences/KDE/share/config, btw.

Note however that I won't be able to do anything about the flashing you mention (if it's anything other than the known glitches which can be avoided by using QtCurve). But you can experiment with --graphicssystem opengl or by setting the RasterOff environment variable.

Thank you for that. My "uber-problem" is now solved - setting 'RasterOff' cured the flickering. For what it's worth, yes QtCurve does build correctly. If you want to continue and try and solve the kde4-workspace non-building problem, I'm happy to keep running tests, but essentially I'm happy with the current outcome. Thanks again for your speedy and insightful responses.

[RJVB (René Bertin)]

Good to hear that! Someone (@nicos?) should try to make "non raster mode" the default on 10.14 and newer then!

As to continuing with this ticket: I'm flabbergasted by it and thus would like to figure out what's going on - on a backburner. The ball is in your camp; I gave some suggestions that you could try; I also asked for guidance on a KDE ML.

Note that with Qt4/KDE4 you can also use qtconfig to set a different default widget style; you'd have to do in that utility too anyway.

[cs0rfecs0rfe (Ian Ferguson)]

Replying to RJVB:

Good to hear that! Someone (@nicos?) should try to make "non raster mode" the default on 10.14 and newer then!

As to continuing with this ticket: I'm flabbergasted by it and thus would like to figure out what's going on - on a backburner. The ball is in your camp; I gave some suggestions that you could try; I also asked for guidance on a KDE ML.

Note that with Qt4/KDE4 you can also use qtconfig to set a different default widget style; you'd have to do in that utility too anyway.

I'll keep going in backburner mode then. I'd missed your suggestions in comment 12 so I'll give them a try and get back to you. I'm not sure what you mean by "guidance on a KDE ML" though?

[RJVB (René Bertin)]

port dir patch take 2

[RJVB (René Bertin)]

I am hoping to get some insight from a KDE mailing list (frameworks-devel).

Meanwhile here's another thing you can try. Revert my earlier patch with

(cd `port dir kde4-workspace`/../.. ; patch -Np1 -R -i /path/to/kde4-workspace.diff)

and then apply the newly attached patch kde4-workspace.2.diff .

This injects a hack into the kde-workspace build system that disables the use of hidden visibility.

[jjstickel (Jonathan Stickel)]

Replying to cs0rfecs0rfe:

Thank you for that. My "uber-problem" is now solved - setting 'RasterOff' cured the flickering. For what it's worth, yes QtCurve does build correctly. If you want to continue and try and solve the kde4-workspace non-building problem, I'm happy to keep running tests, but essentially I'm happy with the current outcome. Thanks again for your speedy and insightful responses.

Where do you set 'RasterOff'? It is not clear from this thread. Thanks!

[RJVB (René Bertin)]

RasterOff is an environment variable, so there are various ways to set it, including in your .login or .profile or .cshrc file.

It looks though that port:kdelibs4 needs to be modified for 10.14, so that RasterOff becomes the default for all KDE applications (it should already be for "pure" Qt4 apps, I think). That'd be for @nicos...

[jjstickel (Jonathan Stickel)]

Replying to RJVB:

RasterOff is an environment variable, so there are various ways to set it, including in your .login or .profile or .cshrc file.

Ah, OK. This seems strange to me. At first I thought it should go in kdeglobals. Having export RasterOff=true in .profile does work, but only if you launch the kde apps from the terminal, for example open -a kwrite. I found that using EnvPane (​https://github.com/hschmidt/EnvPane) was a better overall solution.

It looks though that port:kdelibs4 needs to be modified for 10.14, so that RasterOff becomes the default for all KDE applications (it should already be for "pure" Qt4 apps, I think). That'd be for @nicos...

That would be great. I'll open a ticket if someone else hasn't.

[RJVB (René Bertin)]

Replying to jjstickel:

Ah, OK. This seems strange to me. At first I thought it should go in kdeglobals.

Not strange; it's the cheapest way to implement control over a setting that is not expected to need changing.

You're the one who confirmed that RasterOff=1 does the trick on 10.14, so the honour of filing a ticket goes to you AFAIC ;) If you do make sure to refer to this ticket, and you can also point Nicos to a KCM that should be useful (​https://www.linux-apps.com/content/show.php?content=129817).

[jjstickel (Jonathan Stickel)]

I created a pull request for the Raster issue here: ​https://github.com/macports/macports-ports/pull/2974

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #57566 which is on High Sierra but with Xcode 10.1.

[RJVB (René Bertin)]

Replying to RJVB:

I am hoping to get some insight from a KDE mailing list (frameworks-devel).

Nothing, of course. I may have identified a similar issue in KF5 code however, and might file a bug report for that.

Meanwhile here's another thing you can try. Revert my earlier patch with

(cd `port dir kde4-workspace`/../.. ; patch -Np1 -R -i /path/to/kde4-workspace.diff)

and then apply the newly attached patch kde4-workspace.2.diff .

This injects a hack into the kde-workspace build system that disables the use of hidden visibility.

Has this been tried? Has anyone tried using a MacPorts clang compiler? (configure.compiler=macports-clang-N where N is 5.0 or higher)?

If all else fails I could talk willing volunteers through installing my version of the GCC 7.3 compiler that has a -stdlib=libc++ option.

[jjstickel (Jonathan Stickel)]

Applying your patch kde4-workspace.2.diff worked for me.

[RJVB (René Bertin)]

whew, thanks for the heads-up.

[gusbemacbe (Gustavo Reis)]

As you seem to fix it, may I reinstall kde4-workspace or do I have to wait?

[RJVB (René Bertin)]

not sure what you mean?

If you currently have kde4-workspace installed there is no point in reinstalling. I cannot make changes myself to the official kde4-workspace port, so I have to ask someone, and those changes will only affect how it's built (without hiding private symbols in libraries). There should be no effect on runtime behaviour at all.

[RJVB (René Bertin)]

​https://github.com/macports/macports-ports/pull/2994

[pmetzger (Perry E. Metzger)]

Should now be fixed.