kdelibs4 @4.8.2_0 __KDE_HAVE_GCC_VISIBILITY not defined in <prefix>/include/kdemacros.h

[IanWadham]

The file <prefix>/include/kdemacros.h is apparently generated by the CMake script <prefix>/share/apps/cmake/modules/FindKDE4Internal.cmake, where the KDE build tries to establish the compiler environment. After my kdelibs4 @4.8.2_0 install, I found that no other libraries I compiled and built with #include kdemacros.h could be linked to applications code (I have a development version of KDE Games on Apple). The reason was that GCC visibility of library classes and symbols was not available, because kdemacros.h did not have __KDE_HAVE_GCC_VISIBILITY defined.

Macports 2.0.4, XCode 4.2.1 and OSX 10.7.4 are giving me the symbolic link /usr/bin/c++ -> llvm-g++-4.2 When I force definition of __KDE_HAVE_GCC_VISIBILITY in my CMakeLists.txt, everything compiles and links OK and works fine. So I guess llvm-g++-4.2 is a GCC-like compiler, but is not being recognised as such.

[IanWadham]

Replying to ryandesign@…: FYI, I have also filed a bug report against KDE buildsystem, see ​https://bugs.kde.org/show_bug.cgi?id=300429 Hoping you can help each other.

[mkae (Marko Käning)]

Cc Me!

[IanWadham]

My bug report on ​https://bugs.kde.org/show_bug.cgi?id=300429 has been taken up in the last week by Raphael Kubo da Costa <rakuco@…> who is one of the KDE build system guys. The current state of play is that he would like to see the CMake output from building kdelibs4 @4.8.2_0, but I do not know how to produce that in Macports. I will ask on the Macports users list, but maybe you can help Raphael more directly.

Please refer to the correspondence about this on KDE bug report 300429 (see link above). Basically, something seems to be going wrong when the KDE libs build scripts test the compiler Macports is using to build kdelibs4 @4.8.2_0 (/usr/bin/c++ -> llvm-g++-4.2) and then they fail to see it as a GCC compiler. This problem did not happen with kdelibs4 @4.7.4_0.

[IanWadham]

Looking at the CMake output for kdelibs4 @4.8.2_0, Macports is using the clang compiler to build kdelibs4 @4.8.2_0 and other ports that depend on it, such as kdegames4 @4.8.2_0. kdelibs4 configures its CMake macros accordingly, but they do not necessarily work when they encounter a different compiler. When I compile my own code with clang (KDE Games' SVN trunk and my contributions), everything works fine. However, OS X on my machine is configured with /usr/bin/c++ linked to a different compiler --- llvm-g++-4.2 --- and the KDE macros fail when I use that compiler, leading to linker errors.

I have also written about this on ​https://bugs.kde.org/show_bug.cgi?id=300429

[IanWadham]

Replying to iandw.au@…:

Looking at the CMake output for kdelibs4 @4.8.2_0, Macports is using the clang compiler to build kdelibs4 @4.8.2_0 and other ports that depend on it, such as kdegames4 @4.8.2_0. kdelibs4 configures its CMake macros accordingly, but they do not necessarily work when they encounter a different compiler. When I compile my own code with clang (KDE Games' SVN trunk and my contributions), everything works fine. However, OS X on my machine is configured with /usr/bin/c++ linked to a different compiler --- llvm-g++-4.2 --- and the KDE macros fail when I use that compiler, leading to linker errors.

I have also written about this on ​https://bugs.kde.org/show_bug.cgi?id=300429

This ticket can be closed now.

See ​https://bugs.kde.org/show_bug.cgi?id=300429#c16 for the KDE build-system developer's detailed explanation of this problem. In summary, the KDE project is intending to use clang in the future, but its build macros are not ready for that yet. It is OK to build KDE modules and apps with clang as long as all of them are built with clang. The worst problem is that KDE will export many more symbols than necessary if you use clang, leading to unnecessarily large object files, but otherwise harmless.

[jgosmann (Jan Gosmann)]

Cc Me!