Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#63460 closed defect (fixed)

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

Reported by: tehcog (tehcog) Owned by: michaelld (Michael Dickens)
Priority: High Milestone:
Component: ports Version: 2.7.1
Keywords: lion mavericks Cc: fhgwright (Fred Wright)
Port: cmake

Description

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.

Attachments (4)

cmake_main.log (156.7 KB) - added by tehcog (tehcog) 3 years ago.
main.log
cmake_bootstrap.log (70.2 KB) - added by tehcog (tehcog) 3 years ago.
bootstrap.log
main-107.log (185.1 KB) - added by fhgwright (Fred Wright) 3 years ago.
main-108.log (178.3 KB) - added by fhgwright (Fred Wright) 3 years ago.

Download all attachments as: .zip

Change History (31)

Changed 3 years ago by tehcog (tehcog)

Attachment: cmake_main.log added

main.log

Changed 3 years ago by tehcog (tehcog)

Attachment: cmake_bootstrap.log added

bootstrap.log

comment:1 Changed 3 years ago by 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.

comment:2 in reply to:  1 Changed 3 years ago by 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?

comment:3 Changed 3 years ago by 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

comment:4 in reply to:  3 Changed 3 years ago by 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

comment:5 Changed 3 years ago by 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.

comment:6 in reply to:  5 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by kencu (Ken)

Cc: michaelld removed
Owner: set to michaelld
Status: newassigned

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

comment:10 Changed 3 years ago by fhgwright (Fred Wright)

Cc: fhgwright added

comment:11 Changed 3 years ago by kencu (Ken)

Keywords: lion mavericks added
Summary: cmake-3.21.2_0 fails to configure on maverickscmake-3.21.2_0 fails to configure on older Xcode clang versions

same thing on Lion, no surprise.

Version 0, edited 3 years ago by kencu (Ken) (next)

comment:12 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Priority: NormalHigh

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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

comment:16 Changed 3 years ago by 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.

comment:17 Changed 3 years ago by 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 :)

comment:18 Changed 3 years ago by 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

comment:19 Changed 3 years ago by 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.

comment:20 Changed 3 years ago by 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);

comment:21 Changed 3 years ago by 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.

comment:23 Changed 3 years ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

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

comment:24 Changed 3 years ago by fhgwright (Fred Wright)

Resolution: fixed
Status: closedreopened

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

Changed 3 years ago by fhgwright (Fred Wright)

Attachment: main-107.log added

Changed 3 years ago by fhgwright (Fred Wright)

Attachment: main-108.log added

comment:25 Changed 3 years ago by 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.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:26 Changed 3 years ago by kencu (Ken)

Resolution: fixed
Status: reopenedclosed

comment:27 in reply to:  25 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.