cmake: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)

[ryandesign (Ryan Carsten Schmidt)]

Configuring kdelibs4 fails on Mavericks:

Change Dir: /opt/local/var/macports/build/_Users_rschmidt_macports_dports_kde_kdelibs4/kdelibs4/work/build/CMakeFiles/CMakeTmp

Run Build Command:/opt/local/bin/gmake "cmTryCompileExec2537301723/fast"
/opt/local/bin/gmake -f CMakeFiles/cmTryCompileExec2537301723.dir/build.make CMakeFiles/cmTryCompileExec2537301723.dir/build
gmake[1]: Entering directory `/opt/local/var/macports/build/_Users_rschmidt_macports_dports_kde_kdelibs4/kdelibs4/work/build/CMakeFiles/CMakeTmp'
/opt/local/bin/cmake -E cmake_progress_report /opt/local/var/macports/build/_Users_rschmidt_macports_dports_kde_kdelibs4/kdelibs4/work/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec2537301723.dir/check_qt_visibility.cpp.o
/usr/bin/clang++    -pipe -Os -isystem/opt/local/include -arch x86_64 -stdlib=libc++  -fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -Woverloaded-virtual -fno-exceptions -DQT_NO_EXCEPTIONS -fno-common -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -fdelayed-template-parsing -Wno-return-type-c-linkage  -arch x86_64 -I/opt/local/include/phonon -I/opt/local/include/QtXmlPatterns -I/opt/local/include/QtXml -I/opt/local/include/QtWebKit -I/opt/local/include/QtUiTools -I/opt/local/include/QtTest -I/opt/local/include/QtSvg -I/opt/local/include/QtSql -I/opt/local/include/QtScriptTools -I/opt/local/include/QtScript -I/opt/local/include/QtOpenGL -I/opt/local/include/QtNetwork -I/opt/local/include/QtMultimedia -I/opt/local/include/QtHelp -I/opt/local/include/QtDesigner -I/opt/local/include/QtDeclarative -I/opt/local/include/QtDBus -I/opt/local/include/Qt3Support -I/opt/local/include/QtGui -I/opt/local/include/QtCore -I/opt/local/include -I/opt/local/share/qt4/mkspecs/default    -o CMakeFiles/cmTryCompileExec2537301723.dir/check_qt_visibility.cpp.o -c /opt/local/var/macports/build/_Users_rschmidt_macports_dports_kde_kdelibs4/kdelibs4/work/build/CMakeTmp/check_qt_visibility.cpp
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
gmake[1]: *** [CMakeFiles/cmTryCompileExec2537301723.dir/check_qt_visibility.cpp.o] Error 1
gmake[1]: Leaving directory `/opt/local/var/macports/build/_Users_rschmidt_macports_dports_kde_kdelibs4/kdelibs4/work/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec2537301723/fast] Error 2

CMake Error at cmake/modules/FindKDE4Internal.cmake:1362 (message):
  Qt compiled without support for -fvisibility=hidden.  This will break
  plugins and linking of some applications.  Please fix your Qt installation
  (try passing --reduce-exports to configure).
Call Stack (most recent call first):
  CMakeLists.txt:56 (find_package)

I suspect this began when the cmake portgroup was recently changed. Prior to that, kdelibs4 installed successfully on Mavericks.

This problem affects multiple ports: kdelibs4, kdepimlibs4, probably others.

[NicosPavlov]

Thanks for the report, I was not aware that this error was so widespread. I however doubt it is solely due to changes in the cmake portgroup, because I experienced a similar error 3 weeks ago with kdevelop, but I thought at the time it was isolated. It happened previously with 10.8, and I could solve this particular case by ensuring that the clang compiler was recent enough (>= 3.3).

On another note, this message seems flawed, because for what I searched before, even when qt4-mac is built with -fvisibility-hidden (and it is by default), this error was popping out. For confirmation, does your ${prefix}/include/Qt/qglobal.h file defines QT_VISIBILITY_AVAILABLE ? If yes, that means that the test does not work.

We would need to either correct the compilation line in the test, or just remove it if we are sure that qt4-mac always builds with -fvisibility-hidden, but that seems to be the case (I did not check thoroughly yet).

[ryandesign (Ryan Carsten Schmidt)]

Replying to nicos@…:

Thanks for the report, I was not aware that this error was so widespread. I however doubt it is solely due to changes in the cmake portgroup, because I experienced a similar error 3 weeks ago with kdevelop, but I thought at the time it was isolated. It happened previously with 10.8, and I could solve this particular case by ensuring that the clang compiler was recent enough (>= 3.3).

I thought the recent changes caused the value of configure.cxx_stdlib to be honored by the cmake portgroup for the first time (c.f. r112840), but reviewing all the changes now that doesn't seem to be the case; the flag was probably honored before. So now I don't know what caused the problem to appear when it didn't appear for me on Mavericks before.

On another note, this message seems flawed, because for what I searched before, even when qt4-mac is built with -fvisibility-hidden (and it is by default), this error was popping out. For confirmation, does your ${prefix}/include/Qt/qglobal.h file defines QT_VISIBILITY_AVAILABLE ? If yes, that means that the test does not work.

Doesn't look like it:

$ grep QT_VISIBILITY_AVAILABLE /opt/local/include/Qt/qglobal.h
$ port provides /opt/local/include/Qt/qglobal.h
/opt/local/include/Qt/qglobal.h is provided by: qt4-mac
$ port -v installed qt4-mac
The following ports are currently installed:
  qt4-mac @4.8.5_0+universal (active) platform='darwin 13' archs='i386 x86_64'
$

[NicosPavlov]

Replying to ryandesign@…:

I thought the recent changes caused the value of configure.cxx_stdlib to be honored by the cmake portgroup for the first time (c.f. r112840), but reviewing all the changes now that doesn't seem to be the case; the flag was probably honored before. So now I don't know what caused the problem to appear when it didn't appear for me on Mavericks before.

I did not figure out yet why this error pops out, and it is still erratic to me. I experienced it on 10.8 once, it appeared here, but the example of ticket #41326 shows that in other cases on Maverick, it goes through (to then reach another error, but that's another story). I'll have to make test when getting Mavericks. This test was also introduced rather recently in KDE.

On another note, this message seems flawed, because for what I searched before, even when qt4-mac is built with -fvisibility-hidden (and it is by default), this error was popping out. For confirmation, does your ${prefix}/include/Qt/qglobal.h file defines QT_VISIBILITY_AVAILABLE ? If yes, that means that the test does not work.

Doesn't look like it:

$ grep QT_VISIBILITY_AVAILABLE /opt/local/include/Qt/qglobal.h
$ port provides /opt/local/include/Qt/qglobal.h
/opt/local/include/Qt/qglobal.h is provided by: qt4-mac
$ port -v installed qt4-mac
The following ports are currently installed:
  qt4-mac @4.8.5_0+universal (active) platform='darwin 13' archs='i386 x86_64'
$

Ok, that's helpful. At least in this case, the error appears for the right reason, and it contradicts my previous experience that the test was flawed.

[NicosPavlov]

In the end, I did not encounter this error when testing ports again on Mavericks.

As a follow-up, I noticed that on more recent installs, the file /opt/local/include/Qt/qglobal.h is only a stub pointing to:

#include "../QtCore/qglobal.h"

Then, on my system, testing for the variable shows that it is present:

grep QT_VISIBILITY_AVAILABLE /opt/local/include/QtCore/qglobal.h 
#  define QT_VISIBILITY_AVAILABLE
#  elif defined(QT_VISIBILITY_AVAILABLE)

[ryandesign (Ryan Carsten Schmidt)]

Replying to nicos@…:

In the end, I did not encounter this error when testing ports again on Mavericks.

I still do.

As a follow-up, I noticed that on more recent installs, the file /opt/local/include/Qt/qglobal.h is only a stub pointing to:

#include "../QtCore/qglobal.h"

Yes.

Then, on my system, testing for the variable shows that it is present:

grep QT_VISIBILITY_AVAILABLE /opt/local/include/QtCore/qglobal.h 
#  define QT_VISIBILITY_AVAILABLE
#  elif defined(QT_VISIBILITY_AVAILABLE)

Yes, those lines are present on my system too. I don't think that #define QT_VISIBILITY_AVAILABLE is happening there on OS X; it's inside a block designed to only be used on ​Symbian.

[NicosPavlov]

Right, I did not check the enclosing conditions... However, performing the test that FindKDE4Internal.cmake does works for me, which is to try to compile a file defined as:

#include <QtCore/QtGlobal>
int main() {
#ifndef QT_VISIBILITY_AVAILABLE
#error QT_VISIBILITY_AVAILABLE is not available
#endif 
}

and then running

clang -I/opt/local/include test.c

I noticed that QT_VISIBILITY_AVAILABLE is still defined on OS X because it is declared in qconfig.h (full path /opt/local/Library/Frameworks/QtCore.framework/Versions/4/Headers/qconfig.h) on my system. This is consistent also with the build log of qt4-mac, where the flags are indeed used during compilation:

/usr/bin/clang++ -c -pipe -Os -Xarch_i386 -mmacosx-version-min=10.9 -Xarch_x86_64 -mmacosx-version-min=10.9 -O2 -fvisibility=hidden -fvisibility-inlines-hidden ...

I also tested the +universal variant, as it is what you have if I am not mistaken, and these flags are also defined in the case of +universal (see just above), and I could build kdelibs4+universal. This means that I still have some issues understanding in which case this error occurs, as I only encountered it randomly quite some time ago on 10.8 before this report. For what I could see, the 10.9 build bot also seems to compile the basic kde ports without errors, for example:

Building kdelibs4 (497 of 17941)...success
Building kde4-baseapps (1987 of 17941)...success

[ryandesign (Ryan Carsten Schmidt)]

I think we're on the wrong track above.

I'm using MacPorts trunk, which passes -stdlib=${configure.cxx_stdlib} in CXXFLAGS. On Mavericks, ${configure.cxx_stdlib} defaults to libc++ while on earlier OS X versions it defaults to libstdc++, but it can be changed in macports.conf if you're adventurous and rebuild all your ports afterward. MacPorts 2.2.x and earlier don't pass this flag, instead letting the compiler use its default C++ library.

Furthermore the cmake portgroup sets MACOSX_DEPLOYMENT_TARGET to the empty string. I suspect the KDE cmake files are actively checking MACOSX_DEPLOYMENT_TARGET and are determining that "" is not greater than or equal to "10.7" and therefore print the error.

I tried changing the cmake portgroup to set MACOSX_DEPLOYMENT_TARGET to ${macosx_deployment_target} but this met with a new error:

CMake Error at /opt/local/share/cmake-2.8/Modules/Platform/Darwin.cmake:211 (message):
  CMAKE_OSX_DEPLOYMENT_TARGET is '10.9' but CMAKE_OSX_SYSROOT:

   "/"

  is not set to a MacOSX SDK with a recognized version.  Either set
  CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
  empty.

I remember we don't want to unconditionally set CMAKE_OSX_SYSROOT to an actual SDK, so this is not the right fix. But this shows that setting CMAKE_OSX_DEPLOYMENT_TARGET is a valid and recommended thing to do. I just don't think KDE's cmake files know that or were expecting that.

I think the fix will be to educate the KDE cmake files that when MACOSX_DEPLOYMENT_TARGET is empty it should instead use the current OS X version when checking whether -stdlib=libc++ is acceptable.

[ryandesign (Ryan Carsten Schmidt)]

Actually the error is coming from clang. So we need to set MACOSX_DEPLOYMENT_TARGET correctly. So maybe it's cmake that's wrong (it certainly wouldn't be the first time): maybe cmake shouldn't be complaining at us about setting MACOSX_DEPLOYMENT_TARGET when CMAKE_OSX_SYSROOT is set to "/".

I don't remember why we didn't want to set a complete SDK path, I just remember it not working well. Part of the problem might have been that MacPorts doesn't give us a variable containing the SDK path, and the SDK path has varied several times with different Xcode versions. It would take some research to find out all the possibilities and write them into the cmake portgroup.

But I don't think that's the only thing; I think there were actually problems using an SDK when it wasn't needed. Here are some relevant revisions in the history of the cmake portgroup; I haven't yet looked into these:

• r60805: only use SDK when needed in cmake portgroup
• r66929: configure.sdkroot support
• r73038: pick up sdkroot for universal on ppc tiger
• r78651: set sysroot to / when an SDK is not needed (see #29008, #29452)
• r101141: Ensure that CMAKE_OSX_DEPLOYMENT_TARGET is unset if CMAKE_OSX_SYSROOT is /
• r101169: Revise the previous commit to just not set CMAKE_OSX_SYSROOT or CMAKE_OSX_DEPLOYMENT_TARGET in that case (#37527)
• r101420: Revert r101169 with added comment as to why it's needed

[ryandesign (Ryan Carsten Schmidt)]

I'm calling this a problem with either the cmake portgroup or the cmake port.

[ryandesign (Ryan Carsten Schmidt)]

Still not sure why the KDE ports are affected by this issue but other ports that use cmake, like graphite2, aren't.

Based on r78651 I think the only reason why we're not setting the SDK all the time is that it was a problem with Tiger's gcc-4.0. So we could just special-case Tiger, and use the right SDK on every later OS.

Where should this be done? It could be in the cmake portgroup if we want to replicate the logic from base for finding the SDK based on the Xcode version. Or we could make the change in base, thus actually setting ${configure.sdkroot} in most cases, thus actually passing the -isysroot flag in most cases. This has the potential for causing build failures in ports that'd not properly support switching the SDK, but it might be a good idea to become aware of and fix those problems.

We could potentially avoid the special case for Tiger by switching the default compiler for Tiger to the apple-gcc42 port; this would also help with #40656.

[NicosPavlov]

Right, this makes indeed quite more sense. I am however not fully sure that cmake is fully to blame here. The error occurs at a very specific place, which is at configure stage, not during the build. By looking at the build log on my system, -stdlib=libc++ flag is not set during the standard build stage.

The error occurs during a very specific test performed in kdelibs4 (FindKDE4Internal.cmake):

   # check that Qt defines Q_DECL_EXPORT as __attribute__ ((visibility("default")))
   # if it doesn't and KDE compiles with hidden default visibiltiy plugins will break
   set(_source "#include <QtCore/QtGlobal>\n int main()\n {\n #ifndef QT_VISIBILITY_AVAILABLE \n #error QT_VISIBILITY_AVAILABLE is not available\n #endif \n }\n")
   set(_source_file ${CMAKE_BINARY_DIR}/CMakeTmp/check_qt_visibility.cpp)
   file(WRITE "${_source_file}" "${_source}")
   set(_include_dirs "-DINCLUDE_DIRECTORIES:STRING=${QT_INCLUDES}")
   try_compile(_compile_result ${CMAKE_BINARY_DIR} ${_source_file} CMAKE_FLAGS "${_include_dirs}" OUTPUT_VARIABLE _compile_output_var)
   if(NOT _compile_result)
       message("${_compile_output_var}")
       message(FATAL_ERROR "Qt compiled without support for -fvisibility=hidden. This will break plugins and linking of some applications. Please fix your Qt installation (try passing --reduce-exports to configure).")

The output message is misleading, as the test fails for a reason which is different from what is tested (leading to my errands above). But it still seems that the flags used during this test are different from the ones then really employed at build stage, which may be the reason why kde ports are specifically affected. I will try to have a look to see why the flags are different, which I did not do yet.

For reference, here are the flags which are used on my system (Mavericks, Xcode 5.0.2) at the build stage:

/usr/bin/clang++   -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=97 -DKDE_DEPRECATED_WARNINGS -DQT_NO_CAST_TO_ASCII -DQT_NO_STL -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -D_REENTRANT -pipe -Os -arch x86_64  -fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -Woverloaded-virtual -fno-common -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -Wno-return-type-c-linkage -O2 -DNDEBUG -DQT_NO_DEBUG -arch x86_64

[ryandesign (Ryan Carsten Schmidt)]

Replying to nicos@…:

By looking at the build log on my system, -stdlib=libc++ flag is not set during the standard build stage.

That's expected, if you're running MacPorts 2.2.1. You'll only see that flag if you compile MacPorts base from trunk.

[cooljeanius (Eric Gallager)]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[mkae (Marko Käning)]

I have recently run into this.

Herewith I want to point out that in my case it was possible to build the KDE application from the command line without running into this error.

The question is now why CMake isn't properly configuring anymore when running in a MacPorts build environment?

[ryandesign (Ryan Carsten Schmidt)]

proposed patch for cmake 1.0 portgroup

[ryandesign (Ryan Carsten Schmidt)]

Please test again with MacPorts 2.3.0beta1 and the attached diff for the cmake 1.0 portgroup.

[mojca (Mojca Miklavec)]

Personal reminder: test this patch also with ports using Fortran (root, plplot, ... #37732).

[mkae (Marko Käning)]

I have 2.2.99 installed + the above cmake patch in place, but a CMake build still fails with the same error message.

[ryandesign (Ryan Carsten Schmidt)]

Oh right, I think you'll need the other patch from #41783 as well. The reason I haven't committed it yet is because it causes a problem when using FSF GCC which I don't know how to solve.

[mkae (Marko Käning)]

Well, unfortunately patching my current MP installation with those two patches DID NOT solve the issue.

[ryandesign (Ryan Carsten Schmidt)]

Oh. I thought that was what had fixed it for me. Then I'm sorry, I don't remember how I fixed it on my system.

[rlhamil]

Cc Me!

[NicosPavlov]

Hello, I had a go at trying to build kde ports with Macports trunk, in order to reproduce the issue above. Even though some of the things I found are slightly repetitive from before or potentially naive, I thought it could be good to list things again, as there were some wrong leads evoked in the ticket, partly because of me.

1. As is, kdelibs4 with trunk fails with cmake complaining about -fvisibility=hidden. As suggested by Ryan, it seems to be because of -stdlib being set while cmake does not recognise the option as it is not aware of the MacOS SDK version. This seems to happen because CMAKE_OSX_DEPLOYMENT_TARGET is set to "".

Apparently, from what follows, both CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT must be set correctly to have the build proceed properly.

2. When using only the patch for cmake-1.0.tcl from this ticket (i.e. setting -DCMAKE_OSX_DEPLOYMENT_TARGET="10.9" for Mavericks for example), it still fails with the error:

   CMake Error at /Users/nicos/opt/share/cmake-2.8/Modules/Platform/Darwin.cmake:211 (message):
     CMAKE_OSX_DEPLOYMENT_TARGET is '10.9' but CMAKE_OSX_SYSROOT:
   
      "/"
   
     is not set to a MacOSX SDK with a recognized version.  Either set
     CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
     empty.
   

which brings back to some known complains of cmake.

3. When using the *two* patches of Ryan (i.e. cmake-1.0.tcl patch as before, but also the patch to portconfigure.tcl to set SYSROOT), the build then works. So that I would disagree with Marko, as it seems to solve the issue for me.

4. When avoiding to set both CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET (as it was performed in r101169), the build works. However, the comment in r101420 seems to indicate that it is not a good solution to have cmake find the SDK by itself, even though I am not fully clear why.

4. I had also tried to set CMAKE_OSX_SYSROOT manually at the level of the cmake portgroup, by using the command

   xcodebuild -sdk macosx -version Path
   

instead of the more manual way of your patch for portconfigure.tcl (patch for cmake portgroup attached). In this case too, the build goes fine. I am aware that using a system call to xcodebuild is not ideal, but this shows that the build can also work by setting CMAKE_OSX_SYSROOT correctly at the level of cmake-1.0.tcl.

From all this, it seems that the problem can be solved with your two patches, Ryan (thanks a lot for that). But if the patch of #41783 causes other issues, I am wondering if it would not be also a solution to set CMAKE_OSX_SYSROOT in the cmake portgroup with the code snippet of portconfigure.tcl. In this case, the problem could perhaps be solved while not generating others: the -isysroot option which breaks FSF GCC is not employed when just setting CMAKE_OSX_SYSROOT, although there may be other issues.

[NicosPavlov]

Patch to cmake portgroup to set CMAKE_OSX_SYSROOT

[mkae (Marko Käning)]

Thanks very much Ryan & Nicos for fixing this!

Your combined patch, Nicos, finally also allowed me to build kmymoney4-devel without problems. During the next days I finally can rebuild also all other pending KDE ports. :-)

[mkae (Marko Käning)]

I have created a local MacPorts tree which has higher priority than my main rsync'ed MacPorts tree.

In there I only inserted the patched cmake1.0.tcl group file below /dports/_resources/port1.0/group which keeps the patched group file on my system until this change has been committed or another solution has been found.

[NicosPavlov]

Has duplicate #43366, although it is reported in this case for Macports 2.2.1, with a standard prefix.

Since several people start having this problem, I also attach a new patch (cmake-1.0-full.diff) which should make it possible to solve the issue only by modifying cmake-1.0.tcl.

However, this issue should be dealt with rather rapidly probably, as the patches will be overwritten each time a user runs selfupdate. Furthermore, it is expected that everyone will have this issue when Macports 2.3.0 is released. I the patch to portconfigure.tcl is not committed, I would tend to use the patch which solves the issue within cmake only, even if it is only temporary.

[NicosPavlov]

Patch to bypass the issue only through changes in cmake-1.0.tcl (simplified)

[NicosPavlov]

With the future release of MacPorts 2.3.0, where this issue would become widespread to all users, I patched cmake-1.0 with the last patch, where the variables CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET are set in the script, for the present case where ${configure.sdkroot} is not set. The patch from Ryan for the case where ${configure.sdkroot} is set, in conjunction with possible changes in portconfigure.tcl is also included just in case.

Committed in r119436. I do not close the ticket yet, as I am not completely sure that this patch would solve all issues.

[NicosPavlov]

Considering that no issues were reported several weeks after the release of MacPorts 2.3.0, the issue is assumed fixed.

[ks+macports@…]

Replying to nicos@…:

Considering that no issues were reported several weeks after the release of MacPorts 2.3.0, the issue is assumed fixed.

Sorry. Seems not to work with 2.3.0 trying to build synergy.

loading initial cache file /Users/charly/packages/macports/MacPorts-2.3.0.install/var/macports/build/_Users_charly_packages_macports_MacPorts-2.3.0.install_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-2.8.12.2/Bootstrap.cmk/InitialCacheFlags.cmake
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
CMake Error at Modules/Platform/Darwin.cmake:211 (message):
  CMAKE_OSX_DEPLOYMENT_TARGET is '10.9' but CMAKE_OSX_SYSROOT:

   ""

  is not set to a MacOSX SDK with a recognized version.  Either set
  CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
  empty.
Call Stack (most recent call first):
  Modules/CMakeSystemSpecificInformation.cmake:36 (include)
  CMakeLists.txt:14 (project)


-- Configuring incomplete, errors occurred!
See also "/Users/charly/packages/macports/MacPorts-2.3.0.install/var/macports/build/_Users_charly_packages_macports_MacPorts-2.3.0.install_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-2.8.12.2/CMakeFiles/CMakeOutput.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
Command failed:  cd "/Users/charly/packages/macports/MacPorts-2.3.0.install/var/macports/build/_Users_charly_packages_macports_MacPorts-2.3.0.install_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-2.8.12.2" && ./configure --prefix=/Users/charly/packages/macports/MacPorts-2.3.0.install --mandir=/share/man --docdir=/share/doc/cmake --parallel=4 --init=/Users/charly/packages/macports/MacPorts-2.3.0.install/var/macports/build/_Users_charly_packages_macports_MacPorts-2.3.0.install_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-2.8.12.2/macports.cmake 
Exit code: 11
Error: org.macports.configure for port cmake returned: configure failure: command execution failed
Warning: targets not executed for cmake: org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
Error: Failed to install cmake
Please see the log file for port cmake for details:
    /Users/charly/packages/macports/MacPorts-2.3.0.install/var/macports/logs/_Users_charly_packages_macports_MacPorts-2.3.0.install_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log

Which further information do you need?

[ks+macports@…]

Cc Me!

[mojca (Mojca Miklavec)]

Reopening based on feedback by "ks" (I didn't try myself).

Please also note that CMake 3.0.0 is out (#42654). You might want to compare 2.8 and 3.0 to see if anything changes.

[ks+macports@…]

Replying to mojca@…:

Reopening based on feedback by "ks" (I didn't try myself).

Please also note that CMake 3.0.0 is out (#42654). You might want to compare 2.8 and 3.0 to see if anything changes.

Please tell me, if I can submit further information on my problem (any logs?).

Or should I try 3.0? Then I think I need some hints how to do this. ;-) I just tried to install synergy and cmake is one of the packages synergy is depending on.

So how can I help to get down to fixing this problem? :)

[NicosPavlov]

Alright. Well, I unfortunately can't reproduce the error, which makes things slightly more complicated. Also, the error is slightly different: originally, both variables were empty, leading to errors in some cases. In the error you report, DEPLOYMENT_TARGET is set, but not SDK_ROOT, which always leads to an error to my understanding. The patch which was applied should have ensured that both are always set, which does not seem to happen in your case.

First, attaching a full build log (main.log file) may be helpful to pinpoint the issue. I also noticed that the synergy Portfile makes some very specific changes to some cmake variables, so just to be sure, it could be interesting to check if other ports using the cmake portgroup are building or not. Some ports you could test to install could be eigen or eigen3, for example. They have the advantage of not having additional dependencies.

[ks+macports@…]

OK. I'm terrible sorry.

It seems the problem has not been the cmake-port but a damaged installation of XCode. To document my problem I reinstalled macports (tried this yesterday already with no success) and Xcode and after this cmake builds (well synergy still doesn't, but that's a topic for another task ;-)

Thanks for your help and sorry again for raising the red light for the wrong reasons.

[NicosPavlov]

OK, no problem about that, better safe than sorry.

Thanks for the feedback anyway. I could not wrap my head about the fact that you had only one variable set after the patch, but I could imagine it happening in case of a broken XCode.

In that case, I will again consider this issue solved until further notice.