Opened 8 weeks ago

Last modified 3 weeks ago

#55104 assigned defect

kde4-workspace: fails to compile on High Sierra

Reported by: meabandit Owned by: RJVB (René Bertin)
Priority: Normal Milestone:
Component: ports Version:
Keywords: highsierra Cc:
Port: kde4-workspace


Find the attached log from clean build with

Attachments (3)

main.log.gz (31.0 KB) - added by meabandit 8 weeks ago.
CMakeError.log (36.3 KB) - added by kencu (Ken) 6 weeks ago.
CMakeOutput.log (80.0 KB) - added by kencu (Ken) 6 weeks ago.

Download all attachments as: .zip

Change History (11)

Changed 8 weeks ago by meabandit

comment:1 Changed 8 weeks ago by mf2k (Frank Schima)

  • Owner set to RJVB
  • Status changed from new to assigned

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

comment:2 Changed 8 weeks ago by RJVB (René Bertin)

Apparently something goes wrong building, a component that we should be able to drop without any loss in functionality.

Can you please do something along the lines

> (cd `port work kde4-workspace`/build ; make -wk)

to check if this is the only component that fails to build?

comment:3 Changed 6 weeks ago by kencu (Ken)

This looked a lot like the error in libalkimia, and indeed, the same fix used there fixes this also:

# darwin17 (and later?) does not export visibile symbols
if { ${os.platform} eq "darwin" && ${os.major} >= 17 } {
    configure.cxxflags-append -D__KDE_HAVE_GCC_VISIBILITY
$ port -v installed kde4-workspace
The following ports are currently installed:
  kde4-workspace @ (active) platform='darwin 17' archs='x86_64' date='2017-10-29T11:31:40-0700'

So there is some kind of systemic change, either in Darwin17 or in Xcode 9 (I don't have a darwin16/Xcode9 setup any more) that is causing this.

Rather than add this bit to every KDE4 port, perhaps someone who knows the guts of this might fix it properly? Or at least we can add this hack into the kde4 1.1 PortGroup so that all the kde ports get it.

Last edited 6 weeks ago by kencu (Ken) (previous) (diff)

comment:4 Changed 6 weeks ago by RJVB (René Bertin)

I wouldn't be surprised if the visibility model has moved to 'hidden by default' in recent compiler versions and/or C++ flavours (I've been running into visibility issues even on 10.9 of late).

Does the AppleClang from Darwin17 still support -fvisibility=hidden? I see several tests

   # visibility support
   check_cxx_compiler_flag(-fvisibility=hidden __KDE_HAVE_GCC_VISIBILITY)
   set( __KDE_HAVE_GCC_VISIBILITY ${__KDE_HAVE_GCC_VISIBILITY} CACHE BOOL "GCC support for hidden visibility")

in the various cmake modules installed by KDElibs4. If I'm not mistaken that will define __KDE_HAVE_GCC_VISIBILITY provided the compiler supports the flag.

You may need to check the cmake error file (probably ${build.dir}/CMakeFiles/CMakeError.log or ${build.dir}/CMakeFiles/CMakeOutput.log) to see what happens with that test.

comment:5 Changed 6 weeks ago by kencu (Ken)

Here are those two files, from a failing build on darwin17 It almost seems like those tests are not even happening...

Last edited 6 weeks ago by kencu (Ken) (previous) (diff)

Changed 6 weeks ago by kencu (Ken)

Changed 6 weeks ago by kencu (Ken)

comment:6 Changed 6 weeks ago by RJVB (René Bertin)

Strange, I cannot seem to find any trace of that the test above is being executed. Maybe it isn't, in which case it would probably indeed make sense to define __KDE_HAVE_GCC_VISIBILITY in the KDE4 PG.

Pinging @nicos...

comment:7 Changed 3 weeks ago by kencu (Ken)

This port still breaks, to no great surprise. I did add the block to the kde4-1.1.tcl file, and so far it seems to work as expected:

if { ${os.platform} eq "darwin" && ${os.major} >= 17 } {
    configure.cxxflags-append -D__KDE_HAVE_GCC_VISIBILITY

comment:8 Changed 3 weeks ago by RJVB (René Bertin)

Is this the only KDE4 port which requires this? Have you tried what happens after you rebuild kde4libs with this flag added, and even if it is still required to keep adding the flag when kde4libs was built with it? (port:kde4libs installs the cmake modules used to determine how KDE4 software is built and just might include this setting too.)

If the KDE4 port:kde4libs build is not affected by this then it should be fine to put that block in the PG. Officially that call would be for @nicos to make, but I'd do it myself if I had commit access.

Note: See TracTickets for help on using tickets.