cmake-3.21.2_0 fails to configure on older Xcode clang versions

[tehcog (tehcog)]

Please see attached log files

--->  Computing dependencies for cmake
--->  Fetching archive for cmake
--->  Attempting to fetch cmake-3.21.2_0.darwin_13.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/cmake
--->  Attempting to fetch cmake-3.21.2_0.darwin_13.x86_64.tbz2 from https://mse.uk.packages.macports.org/cmake
--->  Attempting to fetch cmake-3.21.2_0.darwin_13.x86_64.tbz2 from https://packages.macports.org/cmake
--->  Fetching distfiles for cmake
--->  Attempting to fetch cmake-3.21.2.tar.bz2 from https://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/cmake
--->  Verifying checksums for cmake
--->  Extracting cmake
--->  Applying patches to cmake
--->  Configuring cmake
Error: Failed to configure cmake: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[tehcog (tehcog)]

main.log

[tehcog (tehcog)]

bootstrap.log

[kencu (Ken)]

looks like that clang is unhappy with the new code.

can you try blacklisting your clang to fallback to clang-3.7?

btw I changed clang-5.0 to build with cmake-bootstrap, so we have that as a backup to build cmake too I hope.

[tehcog (tehcog)]

Replying to kencu:

can you try blacklisting your clang to fallback to clang-3.7?

Sure, can you please tell me what you think is the best way to do that?.. 'port select'?

Also, are you droping support for Xcode 6.2?

[kencu (Ken)]

no to us dropping support for Xcode 6.2, although cmake might have :>

Sorry, I saw your name around here for some time, I thought you were up on the MacPorts tricks.

for now, this would be a sufficient test:

sudo port clean cmake
sudo port -v -N install clang-3.7
sudo port -v install cmake configure.compiler=macports-clang-3.7

[tehcog (tehcog)]

Replying to kencu:

for now, this would be a sufficient test:

sudo port clean cmake
sudo port -v -N install clang-3.7
sudo port -v install cmake configure.compiler=macports-clang-3.7

Thanks for that, I saw the 'configure.compiler' option, just wasn't sure how to implement it.

It built fine with clang-3.7

[kencu (Ken)]

so ideally we might see what the changes are in the file that fails, come up with some kind of patch that allows the older clang compilers to still work, and then once we have that, send it upstream as a suggestion perhaps.

In the real world, we are going to more likely blacklist clangs up to the failing one, and have them all build cmake with clang-3.7.

that might allow a fair wack of cleanup in the cmake workarounds too, maybe, of that is the plan we wind up taking.

[tehcog (tehcog)]

Replying to kencu:

Question:

In the failed 'main.log':

:info:configure Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2" && ./bootstrap --prefix=/opt/local --docdir=share/doc/cmake --parallel=8 --init=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/macports.cmake --system-libs --no-system-jsoncpp --no-system-librhash --no-qt-gui -- 
:debug:configure system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2" && ./bootstrap --prefix=/opt/local --docdir=share/doc/cmake --parallel=8 --init=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/macports.cmake --system-libs --no-system-jsoncpp --no-system-librhash --no-qt-gui -- 
:info:configure ---------------------------------------------
:info:configure CMake 3.21.2, Copyright 2000-2021 Kitware, Inc. and Contributors
:info:configure C compiler on this system is: /usr/bin/clang -pipe -Os -arch x86_64  
:info:configure C++ compiler on this system is: /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 -std=gnu++1y  
:info:configure Makefile processor on this system is: gmake
:info:configure /usr/bin/clang++ has setenv
:info:configure /usr/bin/clang++ has unsetenv
:info:configure /usr/bin/clang++ does not have environ in stdlib.h
:info:configure /usr/bin/clang++ has stl wstring
:info:configure /usr/bin/clang++ does not have <ext/stdio_filebuf.h>
:info:configure ---------------------------------------------

It indicates: ':info:configure /usr/bin/clang++ does not have <ext/stdio_filebuf.h>'.

However, in the failed cmake_bootstrap.log:

------------------------------------------
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Source/kwsys/kwsysPlatformTestsCXX.cxx:169:12: fatal error: 'ext/stdio_filebuf.h' file not found
#  include <ext/stdio_filebuf.h>
           ^
1 error generated.
Test failed to compile

It indicates: 'fatal error: 'ext/stdio_filebuf.h' file not found'.

Is there any significance to this?

Thanks.

[kencu (Ken)]

The error during configure seems to be:

390	:info:configure /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 -std=gnu++1y      -DCMAKE_BOOTSTRAP    -DCMake_HAVE_CXX_MAKE_UNIQUE=1   -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Bootstrap.cmk   -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Source   -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Source/LexerParser   -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Utilities/std   -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Utilities  -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Source/cmInstallSubdirectoryGenerator.cxx -o cmInstallSubdirectoryGenerator.o
391	:info:configure /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.21.2/Source/cmInstallRuntimeDependencySet.cxx:60:41: error: chosen constructor is explicit in copy-initialization
392	:info:configure   auto it = targetDepends.insert({ tgt, {} });
393	:info:configure                                         ^~
394	:info:configure /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/set:428:14: note: constructor declared here
395	:info:configure     explicit set(const value_compare& __comp = value_compare())
396	:info:configure              ^
397	:info:configure /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:262:37: note: passing argument to parameter '__y' here
398	:info:configure     pair(const _T1& __x, const _T2& __y)
399	:info:configure                                     ^
400	:info:configure 1 error generated.
401	:info:configure gmake: *** [Makefile:232: cmInstallRuntimeDependencySet.o] Error 1
402	:info:configure gmake: *** Waiting for unfinished jobs....

Which looks like a c++ dialect issue. Ionic fixed another one that looked something like this in cmake before I recall.

But clang-3.7 (and greater) don't barf on this, whereas earlier clangs (Apple or OSF) do, it seems.

[fhgwright (Fred Wright)]

What I see here is:

10.4-10.6 i386 OK
10.6 x86_64 OK
10.7-10.9 x86_64 FAIL
10.10-10.13 x86_64 OK

PPC results will take a while, but it's already made it through the 43-minute configure phase on 10.4.

[kencu (Ken)]

Michael -- you feel like taking on the c++ project, or would you rather blacklist clangs up to & including whatever comes on MacOSX 10.9?

[kencu (Ken)]

to be noted that if we require clang-3.7 to build cmake, clang-3.7 currently requires cctools to run.

And cctools requires llvm, so any system we do that on will have to use cctools +llvm37 or less, otherwise circular dep.

[michaelld (Michael Dickens)]

I'm booting up a MacOSX 10.9 system to work on this issue. Might take a couple days to get it to the point of being useful, but at least I'll have direct on metal (non-VM) functionality.

[michaelld (Michael Dickens)]

That was pretty quick! Here's what I see:

:info:configure /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 -std=gnu++1y      -DCMAKE_BOOTSTRAP    -DCMake_HAVE_CXX_MAKE_UNIQUE=1   -I/opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Bootstrap.cmk   -I/opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Source   -I/opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Source/LexerParser   -I/opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Utilities/std   -I/opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Utilities  -c /opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Source/cmInstallRuntimeDependencySet.cxx -o cmInstallRuntimeDependencySet.o
:info:configure /opt/local/var/macports/build/_Volumes_Common_MacPorts_ports_github_macports_devel_cmake/cmake/work/cmake-3.21.2/Source/cmInstallRuntimeDependencySet.cxx:60:41: error: chosen constructor is explicit in copy-initialization
:info:configure   auto it = targetDepends.insert({ tgt, {} });
:info:configure                                         ^~
:info:configure /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/set:428:14: note: constructor declared here
:info:configure     explicit set(const value_compare& __comp = value_compare())
:info:configure              ^
:info:configure /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:262:37: note: passing argument to parameter '__y' here
:info:configure     pair(const _T1& __x, const _T2& __y)
:info:configure                                     ^
:info:configure 1 error generated.
:info:configure make: *** [cmInstallRuntimeDependencySet.o] Error 1

[michaelld (Michael Dickens)]

This matches what's in the attached logfile. My guess is that CMake's scripts are not compatible with this version of clang and/or vice versa: clang is misleading about what flags it accepts.

% clang++ -v
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

This is Xcode 6.2: "Xcode 6.2 is the last release of Xcode that supports running on OS X Mavericks." according to ​Apple's docs.

[michaelld (Michael Dickens)]

Beyond trying out actual C++ code, is there a way to test whether a compiler supports given -std=c++*** or -std=gnu++*** arguments? Have to do some web searching to see ... but maybe someone here knows faster than me :)

[kencu (Ken)]

the clang supports for standards is more of an evolutionary thing rather than a binary thing.

a standard is gradually adopted in one version, and finally covered fully in some often much later version.

here's a useful doc perhaps ​https://clang.llvm.org/cxx_status.html

[kencu (Ken)]

The error:

error: chosen constructor is explicit in copy-initialization

is discussed here <​https://stackoverflow.com/questions/45029992/is-the-stdmap-default-constructor-explicit>

I found a previous similar issue in another project that was fixed by supplying a specific constructor:

​https://github.com/USCiLab/cereal/issues/339

So it appears we can possibly find a way to supply a specific constructor to fix the build with clang-3.4 and other older clang versions, or we can force clang-3.7 or newer, which appear to work.

[kencu (Ken)]

This seems to work:

$ git diff Source/cmInstallRuntimeDependencySet.cxx
diff --git a/Source/cmInstallRuntimeDependencySet.cxx b/Source/cmInstallRuntimeDependencySet.cxx
index 0cef49a..5f826f3 100644
--- a/Source/cmInstallRuntimeDependencySet.cxx
+++ b/Source/cmInstallRuntimeDependencySet.cxx
@@ -57,7 +57,7 @@ const std::set<const cmGeneratorTarget*>& GetTargetDependsClosure(
     targetDepends,
   const cmGeneratorTarget* tgt)
 {
-  auto it = targetDepends.insert({ tgt, {} });
+  auto it = targetDepends.insert({ tgt, {std::set<const cmGeneratorTarget*>{}} });
   auto& retval = it.first->second;
   if (it.second) {
     auto const& deps = tgt->GetGlobalGenerator()->GetTargetDirectDepends(tgt);

[kencu (Ken)]

This is the same fix another user found here:

​https://gitlab.kitware.com/cmake/cmake/-/issues/22609

cmake has not decided whether they will adapt to support these old clangs as yet. I'll PR this change to get us moving while we decide whether to pull the plug and just require a newer clang for cmake going forward.

[kencu (Ken)]

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

[kencu (Ken)]

In 75b47ae5129f873c01bd933c172c6276ece7584c/macports-ports (master):

cmake: fix build with older clangs

use a specified constructor
closes: #63460
see: ​https://gitlab.kitware.com/cmake/cmake/-/issues/22609

[fhgwright (Fred Wright)]

It now builds for 10.9, but 10.7 and 10.8 are still broken.

[kencu (Ken)]

Nope, 10.7 and 10.8 are working great for me, and on the buildbot.

​https://packages.macports.org/cmake/

Your logs just show you haven't got the updated repos with the patch yet.

[fhgwright (Fred Wright)]

Replying to kencu:

Nope, 10.7 and 10.8 are working great for me, and on the buildbot.

​https://packages.macports.org/cmake/

Your logs just show you haven't got the updated repos with the patch yet.

Ah, yes. The ports-tree mirrors were stale at the time, but the confusing thing was that 10.9 worked. That was because it installed that one from binary, while the 10.7 and 10.8 cmakes had previously been infected with "gratuitous universality", and were trying to build from source.