Opened 8 days ago

Closed 2 days ago

Last modified 42 hours ago

#59782 closed defect (fixed)

cmake @3.16.0: error: no matching constructor for initialization of 'const std::vector<ExpectedSpec>'

Reported by: lemzwerg (Werner Lemberg) Owned by: michaelld (Michael Dickens)
Priority: High Milestone:
Component: ports Version: 2.6.99
Keywords: lion Cc:
Port: cmake

Description

:info:build /opt/local/var/macports/build/_opt_macports_macports-ports_devel_cmake/cmake/work/cmake-3.16.0/Tests/CMakeLib/testCTestResourceSpec.cxx:14:40: error: no matching constructor for initialization of 'const std::vector<ExpectedSpec>'

Full log file attached.

Attachments (1)

main.log.xz (24.4 KB) - added by lemzwerg (Werner Lemberg) 8 days ago.

Download all attachments as: .zip

Change History (11)

Changed 8 days ago by lemzwerg (Werner Lemberg)

Attachment: main.log.xz added

comment:1 Changed 8 days ago by jmroot (Joshua Root)

Owner: set to michaelld
Status: newassigned

comment:2 Changed 8 days ago by kencu (Ken)

It's going to completely blow bootstrapping plans, but FYI cmake does build on 10.7 with clang-9.0, at least.

comment:3 Changed 8 days ago by ryandesign (Ryan Schmidt)

Priority: NormalHigh
Summary: cmake 3.16 on Lion: build failscmake @3.16.0: error: no matching constructor for initialization of 'const std::vector<ExpectedSpec>'
Version: 2.6.99

comment:4 Changed 7 days ago by kencu (Ken)

I have a cmake39 port, last that did not require c++11, that could become cmake-bootstrap if we need to go that route.

https://github.com/kencu/myports/tree/master/devel/cmake39

I guess we need to pay closer attention to the devel version; we should have seen this coming.

comment:5 Changed 7 days ago by kencu (Ken)

see also #59780

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

If some c++ genius comes along, perhaps we can figure out how to change the troublesome <vector> code to something that clang-3.4 can understand -- AFAICT it is something to do with the default allocator, and it was fixed in clang-3.7.

I did figure out how to better control the cmake build using the bootstrap script, and you can pass in cmake arguments in the normal way to the bootstrap cmake that is building the final cmake to be installed. That lets you turn off the piece of code that is erroring out, and with that, cmake does build and install with clang-3.4, so our current bootstrapping will continue to work.

This little bit does that (and also, with a small bit of work, we could fully control the cmake build, and pass in all kinds of different, potentially useful, cmake defines that currently aren't able to be used).

$ diff -u Portfile `port file cmake`
--- Portfile	2019-12-05 20:34:42.000000000 -0800
+++ /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/cmake/Portfile	2019-12-05 21:28:44.000000000 -0800
@@ -122,6 +122,9 @@
 # system libuv is the default as of 20160830 (g320f5)
 depends_lib-append  path:lib/pkgconfig/libuv.pc:libuv
 
+configure.cmd       ./bootstrap
+configure.post_args --
+
 configure.env-append \
                     CMAKE_PREFIX_PATH=${prefix} \
                     CMAKE_INCLUDE_PATH=${prefix}/include/ncurses \
@@ -139,6 +142,7 @@
 # Clang 3.4 works. But Clang 3.7 doesn't work.
 if {${os.platform} eq "darwin" && ${os.major} == 11 && ${configure.cxx_stdlib} eq "libc++"} {
     compiler.whitelist macports-clang-3.4
+    configure.post_args-append -DBUILD_TESTING=OFF
 }
 
 platform darwin {
@@ -173,7 +177,6 @@
                     --no-system-librhash
 
 configure.universal_args
-configure.post_args
 
 # CMake's configure script doesn't recognize `--host`.
 array set merger_host {i386 {} x86_64 {} ppc {} ppc64 {}}}}}
Last edited 3 days ago by kencu (Ken) (previous) (diff)

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

One potential solution to this is <https://github.com/macports/macports-ports/pull/5946>.

comment:8 Changed 2 days ago by ken-cunningham-webuse

Resolution: fixed
Status: assignedclosed

In ac9b9592f4e0a909cf85797fe4f601cbade82f7d/macports-ports (master):

cmake: fix build with clang-3.4

enable existing mechanism to pass -DCMAKE arg to cmake during build
disable certain cmake self-tests which currently don't build with clang-3.4
allows bootstrapping with clang-3.4 -> cmake -> clang-3.7
closes: #59782

comment:9 in reply to:  6 Changed 2 days ago by iEFdev (Eric F)

Replying to kencu:

This little bit does that (and also, with a small bit of work, we could fully control the cmake build, and pass in all kinds of different, potentially useful, cmake defines that currently aren't able to be used).

$ diff -u Portfile `port file cmake`
// ... //

Thanks Ken! That one worked for me. Applied the changes from that diff in a local port, for now.


# There's no “CC Me!” in the ticket header?

comment:10 Changed 42 hours ago by lemzwerg (Werner Lemberg)

Yeah, thanks a lot! It worked just fine.

Note: See TracTickets for help on using tickets.