cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system

[ryandesign (Ryan Carsten Schmidt)]

cmake @3.10.0 fails to configure on Mountain Lion and earlier:

Error when bootstrapping CMake:
Cannot find a C++ compiler supporting C++11 on this system.

I thought we weren't going to update cmake to a version that requires C++11 because that destroys MacPorts on earlier systems.

[kencu (Ken)]

I believe if we whitelist clang-3.7 to build cmake on these systems, we should be OK.

Clang-3.7 is the last clang that builds without cmake (at least as configured on MacPorts) and is able to handle c++11, so it should have no trouble building cmake.

For PPC, whitelist gcc6.

[michaelld (Michael Dickens)]

I didn't realize that the 3.10.0 release required C++11. Should have tested on my 10.8 box... hopefully Ken's suggestion works!

[kencu (Ken)]

Surprisingly:

Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0" && ./configure --prefix=/opt/local --docdir=share/doc/cmake --parallel=4 --init=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/macports.cmake --system-libs --no-system-jsoncpp --no-system-librhash --no-qt-gui 
---------------------------------------------
CMake 3.10.0, Copyright 2000-2017 Kitware, Inc. and Contributors
C compiler on this system is: /opt/local/bin/clang-mp-3.7 -pipe -Os -arch x86_64 
---------------------------------------------
Error when bootstrapping CMake:
Cannot find a C++ compiler supporting C++11 on this system.
Please specify one using environment variable CXX.
See cmake_bootstrap.log for compilers attempted.

Perhaps it needs a flag to function. Will explore.

[kencu (Ken)]

Nope. Not a flag. Some kind of weird error in bootstrap:

------------------------------------------
clang: error: unknown argument: '-qlanglvl=extended0x'
Test failed to compile
Checking whether '/opt/local/bin/clang++-mp-3.7 -pipe -Os -stdlib=libstdc++ -arch x86_64 -qlanglvl=extended0x' works.
Try: /opt/local/bin/clang++-mp-3.7
Line: /opt/local/bin/clang++-mp-3.7 -pipe -Os -stdlib=libstdc++ -arch x86_64 -qlanglvl=extended0x cmake_bootstrap_4474_test.cxx -o cmake_bootstrap_4474_test

full log attached. Could be this plan won't work quite so easily - c++11 features in clang-3.7 might only be active if the stdlib is set to libc++. The macports-libstdc++ stuff didn't show up until clang-3.9.

[kencu (Ken)]

bootstrap fail with clang-3.7 / libstdc++ on 10.7

[kencu (Ken)]

looks like that might be it:

Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0" && ./configure --prefix=/opt/local --docdir=share/doc/cmake --parallel=4 --init=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/macports.cmake --system-libs --no-system-jsoncpp --no-system-librhash --no-qt-gui 
---------------------------------------------
CMake 3.10.0, Copyright 2000-2017 Kitware, Inc. and Contributors
C compiler on this system is: /opt/local/bin/clang-mp-3.7 -pipe -Os -arch x86_64 
C++ compiler on this system is: /opt/local/bin/clang++-mp-3.7 -pipe -Os -stdlib=libc++ -arch x86_64 -std=gnu++1z 
Makefile processor on this system is: make
/opt/local/bin/clang++-mp-3.7 has setenv

that's a bit ugly. OK for 10.7+ (just force libc++) but for 10.6, not so simple. Perhaps a simple dependency on port:libcxx might do it, though.

[kencu (Ken)]

Perhaps something like this:

# when using libc++, require Clang 3.4 or newer; Clang 3.3 produces
# bad stream reading code. See also MP ticket #44129:
# < https://trac.macports.org/ticket/44129 >
# cmake no longer bootstraps with a non-c++11 compiler so force clang-3.7 on 
# older systems (last clang that builds without cmake) and require libc++
# to enable c++11 features
platform darwin i386 {
    compiler.blacklist-append {clang < 500} macports-clang-3.3 *gcc*
    if {${os.version} < 13} {
        compiler.blacklist
        compiler.whitelist macports-clang-3.7
        # the following needs to also be available at runtime, note... depends_run-append?
        depends_build-append port:libcxx
        configure.cxx_stdlib libc++
    }
}

platform darwin powerpc {
    compiler.blacklist
    compiler.whitelist macports-gcc-6
}

There are various compiler and stdlib forces in the cmake Portfile that might need to be cleaned up to make sure this works out, including a part where the stdlib is forced back to libstdc++ later on in the portfile (which I've had to delete out of each cmake portfile to build it, btw).

[kencu (Ken)]

Hah. Again, no. Triggers an error during linking on 10.7.

[ 87%] Linking CXX static library libCPackLib.a
cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/Source && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/Bootstrap.cmk/cmake -P CMakeFiles/CPackLib.dir/cmake_clean_target.cmake
cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/Source && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CPackLib.dir/link.txt --verbose=ON
/usr/bin/ar qc libCPackLib.a  CMakeFiles/CPackLib.dir/CPack/cmCPackArchiveGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackComponentGroup.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackGeneratorFactory.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackLog.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackNSISGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackSTGZGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackTGZGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackTXZGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackTarBZip2Generator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackTarCompressGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackZIPGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPack7zGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/cmCPackDebGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/IFW/cmCPackIFWCommon.cxx.o CMakeFiles/CPackLib.dir/CPack/IFW/cmCPackIFWGenerator.cxx.o CMakeFiles/CPackLib.dir/CPack/IFW/cmCPackIFWInstaller.cxx.o CMakeFiles/CPackLib.
ar: CMakeFiles/CPackLib.: No such file or directory
make[2]: *** [Source/libCPackLib.a] Error 1
make[2]: *** Deleting file `Source/libCPackLib.a'
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.10.0'
make[1]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2

[kencu (Ken)]

so I think this clang-3.7/libc++ forcing might be the way forward for bootstrapping most older systems, but we have that issue with 10.7 that apparently is a unique thing. I'll see if that is something easy to fix.

Most likely, all the compiler and stdlib forcing in the cmake Portfile will need to be redone, though.

[kencu (Ken)]

Been playing with variations of this for the morning. It's not an easy fix. The system libs are all installed with a different stdlib than cmake when you force libc++ on 10.7, so that all has to be rethought due to link errors. Frustratingly, the cmake internal libs don't build smoothly on some systems due to all the usual hassles like incorrect typedefs etc. No doubt fixable, but more time. And then the next version of cmake will come out, and we start over again.

I thought perhaps gcc6 might build it (it does on PPC), but sadly even that failed on MacOS Intel.

It's looking more tempting again to spin off the last version as a cmake-legacy port, and use that to step people through to building clang-4.0 or clang-5.0, and then use that to build the current cmake. However, automating that is not simple. People would probably have to follow a page of instructions.

And if they are going to have to do *that* -- well heck, might as well add it as a step to LibcxxOnOlderSystems and be done with it (and fix the buildbot stdlib thing).

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Been playing with variations of this for the morning. It's not an easy fix. The system libs are all installed with a different stdlib than cmake when you force libc++ on 10.7, so that all has to be rethought due to link errors. Frustratingly, the cmake internal libs don't build smoothly on some systems due to all the usual hassles like incorrect typedefs etc. No doubt fixable, but more time. And then the next version of cmake will come out, and we start over again.

I thought perhaps gcc6 might build it (it does on PPC), but sadly even that failed on MacOS Intel.

It's looking more tempting again to spin off the last version as a cmake-legacy port, and use that to step people through to building clang-4.0 or clang-5.0, and then use that to build the current cmake. However, automating that is not simple. People would probably have to follow a page of instructions.

Perhaps you're now understanding why we previously reached the conclusion that C++11 on libstdc++ systems isn't workable?

Maybe I can ask a different question: Why do we need cmake 3.10.0? Can we downgrade to 3.9.6 and keep it there indefinitely? Since 3.10.0 just came out, it seems unlikely that other projects will mandate that version of cmake for another couple years at least. Or, offer 3.10.0 or later to libc++ systems and 3.9.6 to libstdc++ systems. (This has the problem, though, that we also really need to add support to MacPorts base and mprsyncup for separate libc++ portindexes on older systems.)

And if they are going to have to do *that* -- well heck, might as well add it as a step to LibcxxOnOlderSystems and be done with it (and fix the buildbot stdlib thing).

There is no "buildbot stdlib thing" to fix. Virtual machines destined to become buildbot workers for libc++ on 10.6, 10.7 and 10.8 have been provisioned for a year already. For them to become operational, we need to:

1. decide how to differentiate libc++ packages from libstdc++ packages (e.g. how should we change the filename or server URL path)
2. implement that decision in MacPorts base (and, if the server URL path changes, in the buildbot configuration)
3. release a new version of MacPorts base
4. install buildbot on the workers and follow the LibcxxOnOlderSystems instructions there

[kencu (Ken)]

Replying to ryandesign:

Perhaps you're now understanding why we previously reached the conclusion that C++11 on libstdc++ systems isn't workable?

Ryan, I did understand it -- but I also can understand that Michael is not too keen to stop cmake progress for the sake of older systems and I was just trying to help out a bit here as I have all these systems running.

I was not surprised to see Michael press on with cmake newer releases. Other package management systems proceed apace with cmake releases. Without dealing with the issue, we'd be stuck on 3.9 forever, so we might as well sort it out.

There is no "buildbot stdlib thing" to fix.

The steps you outlined are what I was referring to.

It would seem that having a cmake-3.9 pegged cmake port (choose your name - cmake-legacy, cmake-3.9, cmake39, whatever seems popular enough) is trivial to do. It would have to conflict with cmake and cmake-devel, and would not need to coexist. It would fulfill the bin/cmake build dependency outlined in the current cmake PortGroup, so no big issue there.

Somehow have to force that cmake39 version on systems without cmake installed if they try to install something that needs cmake. That would be easy enough to do in the cmake PortGroup, with a system test:

# can use cmake or cmake-devel; default to cmake if not installed

if {${os.version} > 12} {
    depends_build-append path:bin/cmake:cmake
} else {
    depends_build-append path:bin/cmake:cmake39
}

Then - this is what I don't know how to do - someday perhaps automatically have that cmake39 replace itself with cmake once a suitable version of clang is installed. That might have to be a manual step, unless someone sees trickery that could do it.

[ryandesign (Ryan Carsten Schmidt)]

Wouldn't it be simpler to modify the one cmake portfile to:

Replying to ryandesign:

Can we [...] offer 3.10.0 or later to libc++ systems and 3.9.6 to libstdc++ systems.

In other words:

if {${configure.cxx_stdlib} eq "libc++"} {
    version 3.10.0
    ...
} else {
    version 3.9.6
    ...
}

Requires no modification to portgroup or other ports.

[kencu (Ken)]

Something like that might work. But there are hiccups --

10.7 configured to libc++ can't build the current cmake, for example, and has to be forced back to libstdc++ for the build to work. Weird stuff.

systems configured with stdlib=libstdc++ set up with the cxx11 1.1 PG can build the most recent cmake if they have a new clang like clang-5.0 installed, so really shouldn't be held back to 3.9.6. for any particular reason.

Also, if we did spin off cmake39 for older systems, Michael might be able to clean out a lot of legacy crud in that cmake Portfile and start lean and fresh going forward...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I was able to get cmake to build on a 10.7 VM using libstdc++ with the following steps:

1. Change configure.cxx_stdlib libstdc++ to configure.cxx_stdlib macports-libstdc++ in the ​cmake Portfile to allow C++11
2. Create a cmake39 port that does not require C++11 and installs ${prefix}/bin/cmake
3. Add the following code to the the ​cmake PG to avoid circular dependencies

   if {${os.major} < 13 && ([string match clang-* ${subport}] || [string match llvm-* ${subport}] || [string match libomp* ${subport}])} {
       depends_build-append path:bin/cmake:cmake39
   } else {
       # can use cmake or cmake-devel; default to cmake if not installed                                                                                                                                     
       depends_build-append path:bin/cmake:cmake
   }
   

[kencu (Ken)]

I see. cmake 3.9 would be called only to build clang or omp . For any other build, the regular cmake would be called. I see the trick you're thinking of. Just have to make sure that nothing triggers a regular cmake install until after clang-5.0+ is functional. Clever way out of the issue.

I think it would be best if I left the rest of this decision-making process to you and Ryan and Michael, as you all have so much more experience with it and it's so integral to the function of MacPorts.

[michaelld (Michael Dickens)]

has duplicate #55415

[michaelld (Michael Dickens)]

We stopped GLFW release for older Mac OS X 10.6 and older, because the GLFW devs updated to 10.7+ APIs: ​https://github.com/macports/macports-ports/blob/master/graphics/glfw/Portfile#L17 . We can do something similar for CMake, or just offer the cmake39 port as described (with the final version of cmake that doesn't require C++11).

And, maybe #55415 isn't quite a duplicate, but the efforts are similar & the end result is likely to address both tickets.

[kencu (Ken)]

It looks highly likely that part of this fix will involve a cmake39 port. Is everyone OK if I push that through? It will help get peoplr ruuning, and fulfill the cmake test in the cmake PG file.

[ryandesign (Ryan Carsten Schmidt)]

I don't understand how that can work. If cmake and cmake39 conflict and both install /opt/local/bin/cmake, and if you make one of cmake's dependencies depend on cmake39, then cmake will eventually fail to activate because cmake39 is active.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ryandesign:

I don't understand how that can work. If cmake and cmake39 conflict and both install /opt/local/bin/cmake, and if you make one of cmake's dependencies depend on cmake39, then cmake will eventually fail to activate because cmake39 is active.

Wouldn't the following code in the ​cmake PG break the circular dependency?

if {${os.major} < 13 && ([string match clang-* ${subport}] || [string match llvm-* ${subport}] || [string match libomp* ${subport}])} {
    depends_build-append path:bin/cmake:cmake39
} else {
    # can use cmake or cmake-devel; default to cmake if not installed                                                                                                                                     
    depends_build-append path:bin/cmake:cmake
}

[ryandesign (Ryan Carsten Schmidt)]

Not circular dependency; activation conflict.

If you're proposing that cmake should depend on clang-X.Y (where X.Y is 3.8 or greater), and you're proposing that clang-X.Y should depend on cmake39 as a bootstrapping measure, then here's what will happen:

• User requests to install cmake deliberately, or requests to install a port that depends on path:bin/cmake:cmake
• MacPorts installs cmake39
• MacPorts uses cmake39 to build llvm-X.Y and clang-X.Y
• MacPorts builds cmake using clang-X.Y
• cmake fails to activate because it wants to install files that are already installed by cmake39

This could potentially be worked around using the deactivate hack in the cmake port, but that feels fragile. For example, what happens if the user requests to install a port that depends on path:bin/cmake:cmake, and the process is interrupted after cmake39 is installed but before cmake is installed—either due to an error that can be resolved, or just because the user pressed ^C? When the user tries again, /opt/local/bin/cmake will already be there from the cmake39 port and the user will from then on forever use the cmake39 port instead of the cmake port. If that's an acceptable outcome, why not just always offer cmake 3.9.6 to those systems (using a conditional in the cmake port) like I suggested?

If we want to offer cmake 3.10 and later to libstdc++ systems—and I agree it would be best to do so if we can without too much grief for both us and the user—then having a cmake bootstrap port install cmake 3.9.6 to a different private location to avoid activation conflicts would be less error-prone.

But I'm still not clear whether we need a cmake 3.9.6 bootstrap port at all. Can't cmake 3.10+ just build using clang-3.7, which does not depend on cmake, as Ken suggested in comment:1? cmake is only a program, not a library, so nothing will be linking with it; and as far as I can tell, of cmake's dependencies, only the ncurses port contains a library that uses C++, and cmake only links with libncurses, not libncurses++; so it should be fine to force cmake to use libc++ on older systems, just like I do for mongodb for the same reasons ([06570abb7bb41aaf8058fbad159163374a8ed61c/macports-ports], [7339137c4e501aa383516859235fa3fb17906332/macports-ports]).

I'm not sure if we can use libc++ on Tiger and Leopard. I see that the current cmake 3.10.0 port built just fine on 10.5 PPC with gcc6. We could do the same on 10.5 Intel and 10.4. The cxx11-1.1 portgroup currently uses gcc6 only on PowerPC. Maybe it should be changed to use gcc6 on 10.5 and earlier regardless of arch.

[kencu (Ken)]

Sadly, clang-3.7 doesn't understand stdlib=macports-libstdc++, so it can't build c++11 unless libc++ is used. That requires manual steps.

we should not be talking about libc++ really -- all the systems from 10.4 to 10.8 currently get access to c++11 from gcc's libstdc++.

10.4 can't build cmake 3.10.0 due to libuv incompatibilities that we may never figure out. libuv has said they are 10.7+, so we can expect further troubles there in the future.

cmake 3.9.6 should be able to build software that needs cmake for many years. A cmake39 port offers the chance of bootstrapping up to 3.10.x later, either manually or automatically once we figure out how to do that safely (per Marcus). It also would be immune to any future changes in the cmake portfile that Michael might come up that could break cmake 3.9.6.

But we would have years to figure that out, as cmake 3.9.6 will work for a very long time I think.

If we did this in the cmake PortGroup:

if {${os.version} > 12} {
    depends_build-append path:bin/cmake:cmake
} else {
    depends_build-append path:bin/cmake:cmake39
}

and made a cmake39 port, we're done with that for some years.

[kencu (Ken)]

except for some older systems that already have cmake installed, I realize. I can see a situation where some of those will try to upgrade cmake, and probably fail.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Sadly, clang-3.7 doesn't understand stdlib=macports-libstdc++, so it can't build c++11 unless libc++ is used. That requires manual steps.

Yes, I am talking about using libc++.

I made my suggested changes, but cmake is for some reason that I fail to understand failing to find libc++:

    /opt/local/bin/clang++-mp-3.7  -pipe -Os -stdlib=libc++ -arch x86_64  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64  CMakeFiles/cmTC_53c5f.dir/testCXXCompiler.cxx.o  -o cmTC_53c5f 
    ld: library not found for -lc++

It is there:

$ ls -l /usr/lib/libc++.*dylib 
-rwxr-xr-x  1 root  admin  2312760 Feb  2  2017 /usr/lib/libc++.1.dylib
lrwxr-xr-x  1 root  admin       14 Feb  2  2017 /usr/lib/libc++.dylib -> libc++.1.dylib

Oh wait, I see it now... it's because it's looking for it in the SDK. Maybe we should just have the libcxx port also install itself into the SDK.

we should not be talking about libc++ really -- all the systems from 10.4 to 10.8 currently get access to c++11 from gcc's libstdc++.

So you would like to force 10.8 and earlier to use gcc6 to build cmake? I admit I do not understand how this is now possible, since we had previously thought it to be impossible to reliably exchange objects between FSF GCC's libstdc++ and Apple GCC's libstdc++. If it is now possible, I don't understand why we're not always doing that for C++11 support on 10.8 and earlier, and forget about trying to use clang and libc++ there.

10.4 can't build cmake 3.10.0 due to libuv incompatibilities that we may never figure out. libuv has said they are 10.7+, so we can expect further troubles there in the future.

I see. That's unfortunate. Can't we ​tell cmake not to use libuv?

cmake 3.9.6 should be able to build software that needs cmake for many years.

Which is why I suggested that the cmake port offer that version to users of older systems.

A cmake39 port offers the chance of bootstrapping up to 3.10.x later, either manually or automatically once we figure out how to do that safely (per Marcus). It also would be immune to any future changes in the cmake portfile that Michael might come up that could break cmake 3.9.6.

But we would have years to figure that out, as cmake 3.9.6 will work for a very long time I think.

If we did this in the cmake PortGroup:

if {${os.version} > 12} {
    depends_build-append path:bin/cmake:cmake
} else {
    depends_build-append path:bin/cmake:cmake39
}

and made a cmake39 port, we're done with that for some years.

I explained above why this seems much more complicated and potentially unreliable, unless we have cmake39 install to a different prefix, such as /opt/local/libexec/cmake39.

Replying to kencu:

except for some older systems that already have cmake installed, I realize. I can see a situation where some of those will try to upgrade cmake, and probably fail.

Right; another reason to have the bootstrap port install to a different location.

[kencu (Ken)]

So you would like to force 10.8 and earlier to use gcc6 to build cmake?

No. But 10.4 to 10.8, using the cxx11 1.1 PG, currently get a c++11 libstdc++ from libgcc. On PPC, gcc6 builds against that. On Intel on older systems, clang-5.0 builds against it.

I explained above why this seems much more complicated and potentially unreliable, unless we have cmake39 install to a different prefix, such as /opt/local/libexec/cmake39.

I don't quite understand why you think this. Once cmake39 is installed, the cmake dependency is fulfilled.

So as I see it, there are two choices:

1. put a peg in the cmake portfile as you suggested initially, and see how long it lasts until it breaks someday. Easy. Done.
2. make a cmake39 port, and then figure out how to use it properly. For now, using a block similar to the one I mentioned, serve it up to older systems that don't have cmake installed. Older Intel systems that do have cmake installed probably also have clang-5.0 installed, and can build cmake 3.10. If they don't have clang-5.0 installed, they should be able build it with the cmake they have installed already, unless port won't let them do that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

So you would like to force 10.8 and earlier to use gcc6 to build cmake?

No. But 10.4 to 10.8, using the cxx11 1.1 PG, currently get a c++11 libstdc++ from libgcc. On PPC, gcc6 builds against that. On Intel on older systems, clang-5.0 builds against it.

Ah, ok, we're already not-using-libc++ when using cxx11 1.1. My question about why sharing data between FSF GCC libstdc++ and Apple GCC libstdc++ now works when it caused crashes before remain.

Can the macports-libstdc++ stuff be brought back to clang-3.7?

So as I see it, there are two choices:

1. put a peg in the cmake portfile as you suggested initially, and see how long it lasts until it breaks someday. Easy. Done.
2. make a cmake39 port, and then figure out how to use it properly. For now, using a block similar to the one I mentioned, serve it up to older systems that don't have cmake installed. Older Intel systems that do have cmake installed probably also have clang-5.0 installed, and can build cmake 3.10. If they don't have clang-5.0 installed, they should be able build it with the cmake they have installed already, unless port won't let them do that.

You're right that port won't let them do that. If clang-5.0 depends on cmake, and cmake is installed but outdated, MacPorts will try to upgrade cmake first, which would be a circular dependency back to clang-5.0 and will fail with an unintelligible error message.

[kencu (Ken)]

Can the macports-libstdc++ stuff be brought back to clang-3.7?

It may not be impossible. AFAIK it has not be done anywhere. It has been brought back to clang-3.8 using some debian patches <​https://github.com/kencu/LeopardPorts/tree/master/lang/llvm-3.8> . I don't know how much work it would be to find the proper spots in clang-3.7, or if it could be done. But if it could be done, it would indeed solve the problem.

[ryandesign (Ryan Carsten Schmidt)]

I have a working cmake 3.10.0 built with libc++ on 10.6 right now, which would presumably work on 10.7 and 10.8 too. Having some trouble on 10.5 Intel...

[kencu (Ken)]

My question about why sharing data between FSF GCC libstdc++ and Apple GCC libstdc++ now works when it caused >crashes before remain.

It's that magic flag, -D_GLIBCXX_USE_CXX11_ABI=0

I have a working cmake 3.10.0 built with libc++ on 10.6 right now, which would presumably work on 10.7 and 10.8 >too.

The 10.7 build will fail, sadly, as per comment:7

[kencu (Ken)]

That first 10.7 error, by the way, is due to some piece of software that cuts off the generated link line at 1024 characters on 10.7. Josh mentioned some kind of known bug in 10.7 that did something like this, and had a workaround. I don't know if that is what is doing it, exactly, but if we could figure that out, it might be useful.

Even then, as above, once built, it will fail to link unless everything is build against libc++ as per LibcxxOnOlderSystems.

[kencu (Ken)]

I have a working cmake 3.10.0 built with libc++ on 10.6 right now

BTW, that's what I'm using on the machine I am typing this on, configured with LibcxxOnOlderSystems. Works like a charm.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

My question about why sharing data between FSF GCC libstdc++ and Apple GCC libstdc++ now works when it caused >crashes before remain.

It's that magic flag, -D_GLIBCXX_USE_CXX11_ABI=0

As I've mentioned elsewhere, -D_GLIBCXX_USE_CXX11_ABI=1 means use the GCC 5.1+ ABI, and -DGLIBCXX_USE_CXX11_ABI=0 means use the pre-GCC 5.1 ABI. We were experiencing crashes sharing objects between Apple's GCC 4.2.1 libstdc++ and FSF GCC years before the release of GCC 5, so those versions of FSF GCC would have been using the old ABI already.

I have a working cmake 3.10.0 built with libc++ on 10.6 right now, which would presumably work on 10.7 and 10.8 >too.

The 10.7 build will fail, sadly, as per comment:7

Replying to kencu:

That first 10.7 error, by the way, is due to some piece of software that cuts off the generated link line at 1024 characters on 10.7. Josh mentioned some kind of known bug in 10.7 that did something like this, and had a workaround. I don't know if that is what is doing it, exactly, but if we could figure that out, it might be useful.

​Right. That bug(tracker) was closed and no new bug was filed in the new tracker but the issue remains. I'm not familiar with Josh's claim of a workaround.

There was talk in that bug report about possibly being able to replace the problematic GetLineFromStream with std::getline.

Since the problem seems to be that a character is lost or misinterpreted at the 1024-byte buffer size boundary, I wonder how reasonable it would be to just increase the buffer size on Lion to something huge. How long do we thing compile lines might get?

Even then, as above, once built, it will fail to link unless everything is build against libc++ as per LibcxxOnOlderSystems.

I explained above why that's not so. cmake doesn't link with any C++ libraries so it's fine to force it to use libc++ even if none of its dependencies do. I already have this running on an otherwise-libstdc++ 10.6 system.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

​Right. That bug(tracker) was closed and no new bug was filed in the new tracker but the issue remains. I'm not familiar with Josh's claim of a workaround.

Using Michael's test program​ I can confirm that Lion's Xcode clang (Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)) has the bug, and that macports-clang-3.4 does not have the bug, and that macports-clang-3.7 does have the bug (!). If I force the use of clang-3.4, cmake 3.10.0 builds and works on Lion.

[ryandesign (Ryan Carsten Schmidt)]

The attached patches works for me on 10.8 and 10.7, and on 10.6 provided #55441 is implemented. I think these are good to commit but want to attach them for review first.

Note I changed the conditional at the top of the cxx11-1.1 portgroup from ${cxx_stdlib} to ${configure.cxx_stdlib} because I didn't understand why the first was used, and it prevented me from overriding it in the cmake portfile like I wanted to. Michael said on the mailing list that ${cxx_stdlib} is the default value (e.g. set by MacPorts base or by the user in macports.conf) while ${configure.cxx_stdlib} is the current value; seems like we want to check the current value.

On 10.5 i386 I am having other problems: #55442, #55443. On 10.5 ppc, the port already builds successfully with gcc6. We could just give up on libc++ for 10.5 and make the portgroup use gcc6 on 10.5 i386 too.

The libcxx port prevents its installation on 10.4 any arch, so I modified cxx11-1.1 to use gcc6 there as well. I have not tested building on 10.4 yet but can do so tomorrow. But I feel like 10.4 and 10.5 issues are less important and investigating those needn't hold up committing a fix for 10.6-10.8.

I'm going to stop working on this for now and may come back to it tomorrow, if anyone wants to do any other testing or investigations in the mean time.

[kencu (Ken)]

We're working on 10.4 Tiger with cmake 3.10.0 here 55415

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

On 10.5 i386 I am having other problems: #55442, #55443. On 10.5 ppc, the port already builds successfully with gcc6. We could just give up on libc++ for 10.5 and make the portgroup use gcc6 on 10.5 i386 too.

I forgot that libcxx/libcxxabi/libunwind force a universal build. On Leopard/Tiger that would result in ppc code being built, which clang doesn't do. This convinces me that we should forget libc++ for 10.5 and use gcc6 there too.

[kencu (Ken)]

Ryan, cmake links against many system libs, I'm not sure that forcing libc++ is going to work out without a full implementation of LibcxxOnOlderSystems. What am I missing here?

[ryandesign (Ryan Carsten Schmidt)]

From a 10.8 system, with cmake 3.10.0 installed using my patches, here is the complete list of libraries cmake's files link with:

$ port -q contents cmake | sed -E 's/^ +//' | file -e apptype -e ascii -e cdf -e compress -e elf -e encoding -e tar -e tokens --mime-type --no-buffer --no-pad --files-from - | sed -E -n 's,: *application/(octet-stream|x-(archive|mach-binary))$,,p' | tr '\n' '\000' | xargs -0 otool -L | grep -v 'is not an object file'
/opt/local/bin/ccmake:
	/opt/local/lib/libform.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/bin/cmake:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/bin/cmakexbuild:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/bin/cpack:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/bin/ctest:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/share/cmake-3.10/Modules/CPack.OSXScriptLauncher.in (architecture ppc):
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 27.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 106.1.0)
/opt/local/share/cmake-3.10/Modules/CPack.OSXScriptLauncher.in (architecture i386):
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 27.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 106.1.0)

Here is the complete list of libraries those libraries link with:

bash-3.2$ port -q contents cmake | sed -E 's/^ +//' | file -e apptype -e ascii -e cdf -e compress -e elf -e encoding -e tar -e tokens --mime-type --no-buffer --no-pad --files-from - | sed -E -n 's,: *application/(octet-stream|x-(archive|mach-binary))$,,p' | tr '\n' '\000' | xargs -0 otool -L | grep -E -v '(^/|is not an object file)' | awk '{print $1}' | sort -u | xargs otool -L
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/usr/lib/libauto.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libDiagnosticMessagesClient.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 49.1.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices:
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0)
	/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 595.1.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore (compatibility version 1.0.0, current version 1037.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata (compatibility version 1.0.0, current version 705.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices (compatibility version 1.0.0, current version 555.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit (compatibility version 1.0.0, current version 200.1.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 742.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE (compatibility version 1.0.0, current version 644.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices (compatibility version 1.0.0, current version 535.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libarchive.13.dylib:
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/liblzo2.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.3.0)
	/opt/local/lib/liblz4.1.dylib (compatibility version 1.0.0, current version 1.8.0)
	/opt/local/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libcurl.4.dylib:
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libidn2.0.dylib (compatibility version 4.0.0, current version 4.3.0)
	/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libexpat.1.dylib:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libform.6.dylib:
	/opt/local/lib/libform.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libncurses.6.dylib:
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libuv.1.dylib:
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libz.1.dylib:
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/usr/lib/libSystem.B.dylib:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 57.0.0)
	/usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 50000.0.0)
	/usr/lib/system/libcompiler_rt.dylib (compatibility version 1.0.0, current version 30.0.0)
	/usr/lib/system/libcopyfile.dylib (compatibility version 1.0.0, current version 89.0.0)
	/usr/lib/system/libdispatch.dylib (compatibility version 1.0.0, current version 228.23.0)
	/usr/lib/system/libdnsinfo.dylib (compatibility version 1.0.0, current version 453.19.0)
	/usr/lib/system/libdyld.dylib (compatibility version 1.0.0, current version 210.2.3)
	/usr/lib/system/libkeymgr.dylib (compatibility version 1.0.0, current version 25.0.0)
	/usr/lib/system/liblaunch.dylib (compatibility version 1.0.0, current version 442.26.2)
	/usr/lib/system/libmacho.dylib (compatibility version 1.0.0, current version 829.0.0)
	/usr/lib/system/libquarantine.dylib (compatibility version 1.0.0, current version 52.1.0)
	/usr/lib/system/libremovefile.dylib (compatibility version 1.0.0, current version 23.2.0)
	/usr/lib/system/libsystem_blocks.dylib (compatibility version 1.0.0, current version 59.0.0)
	/usr/lib/system/libsystem_c.dylib (compatibility version 1.0.0, current version 825.40.1)
	/usr/lib/system/libsystem_dnssd.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_info.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current version 2050.48.12)
	/usr/lib/system/libsystem_m.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_network.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_notify.dylib (compatibility version 1.0.0, current version 98.5.0)
	/usr/lib/system/libsystem_sandbox.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libunc.dylib (compatibility version 1.0.0, current version 25.0.0)
	/usr/lib/system/libunwind.dylib (compatibility version 1.0.0, current version 35.1.0)
	/usr/lib/system/libxpc.dylib (compatibility version 1.0.0, current version 140.43.0)
/usr/lib/libc++.1.dylib:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 24.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

So yes, cmake's programs link with libc++. But none of the libraries those programs use link with libc++. So it seems clear to me that cmake's programs are not exchanging C++ objects with any of the libraries they use. Therefore it is fine to force cmake to use libc++ even when other ports are using libstdc++.

[ryandesign (Ryan Carsten Schmidt)]

I've used graphite2 as my test case and it seems to build fine on each OS version I've tested so far (10.6-10.8). If there's a different port that builds with cmake that you'd like me to test on those systems I'd be happy to.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ryandesign:

Can the macports-libstdc++ stuff be brought back to clang-3.7?

I have not tested it thoroughly, but attached are two patches that bring the macports-libstdc++ variant to clang-3.7.

[kencu (Ken)]

Marcus, the gcc5-ABI handling ability showed up in clang-3.9.

clang-3.7 doesn't contain the code to make the gcc5 ABI work. Neither did clang-3.8, until some patches on debian were found that apply to clang-3.8.

These are the two patches I use in clang-3.8 to get started. Then I added the macports-libstdc++ bit of yours (but that only works with the patches added below)

<​https://reviews.llvm.org/D18035?id=61350>

<​https://reviews.llvm.org/D17567>

<​https://github.com/kencu/LeopardPorts/blob/master/lang/llvm-3.8/files/4000-patch-clang-lib-codegen-targetinfo-ppc-38.diff>

<​https://github.com/kencu/LeopardPorts/blob/master/lang/llvm-3.8/files/4001-patch-clang-3.8-gccabi-sema.diff>

[ryandesign (Ryan Carsten Schmidt)]

I guess it's not necessary to pursue anymore. You already have a working solution with later clang ports that can be used for anything that's not cmake or its dependencies. As far as I can tell, my patches result in a working cmake 3.10.0 with clang and libc++ on 10.6-10.8 and with gcc6 and libstdc++ on 10.5. Jeremy has already indicated that the clang-3.7 port is not intended for general use anymore:

# This compiler version is not supported beyond these very strict use cases:
#     1) Building newer llvm Mountain Lion (https://trac.macports.org/ticket/53138)
#
# There should be no other usage of clang-3.7 nor llvm-3.7
#
# llvm-3.7 was the last version to use the autoconf build system.  Newer
# versions require cmake to build.  Cmake requires a C++11 toolchain, so
# clang-3.7 is being kept around in order to build cmake (or its dependencies)
# if needed on such systems.

[kencu (Ken)]

Lucky. All those system libraries, none are c++.

However, right now cmake is using an internal copy of jsoncpp. That port links against the standardlib, so if Michael ever changes it to use MacPorts jsoncpp, then the setup would break. Guess he better leave it as it is!

Lots of work to figure this out!

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Lucky. All those system libraries, none are c++.

I think I recall someone mentioning a couple years ago that only one or two system libraries use C++. Which doesn't surprise me, since Apple's languages of choice are Objective-C and Swift, not C++.

However, right now cmake is using an internal copy of jsoncpp. That port links against the standardlib, so if Michael ever changes it to use MacPorts jsoncpp, then the setup would break.

It's also pointed out in an existing comment in the Portfile that the jsoncpp port has a build dependency on cmake, so it's unlikely Michael could change the cmake port to use the jsoncpp port even if he wanted to. I'll modify the comment to mention the C++ library problem too.

[michaelld (Michael Dickens)]

You guys are having way too much fun! ;)

Given that jsoncpp requires cmake for building, and is unlikely to not require it in the future, I think using the cmake-internal version is the way to go. I don't see bootstrapping cmake to build jsoncpp to rebuild cmake as something I have time to work on any time soon, even if I wanted to, which I don't. I have better things to be doing with my time ;)

I could see a future where we copy an external jsoncpp into the cmake code and use it for building cmake, then relink the cmake binary to instead use the already-installer jsoncpp ABI since it would be the same-same as that internal. But, again, I have other/better things to be working on.

Let me know when you're ready to commit.

[kencu (Ken)]

Only thing left is to set a peg @3.9.6 for Tiger - or not. Sometimes I think only Peter and I actually use MacPorts on Tiger, hopefully I'm wrong about that. I already have it pegged in TigerPorts, my Tiger shadow repo.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld:

Let me know when you're ready to commit.

I think my patches are ready to be committed now. You can commit them, or I can, if you prefer.

Leopard and Tiger are blocked by #55440 anyway. Once that's fixed, we can resume working on any remaining cmake problems on those systems.

[michaelld (Michael Dickens)]

Why don't you go ahead and commit them, Ryan (or Ken). It would take me effort to get everything in place, and it sounds like you're ready to go.

[ryandesign (Ryan Carsten Schmidt)]

In da3cd33ba9cb37d97c20c0a8b99ee10f0d889fb1/macports-ports:

cxx11-1.1.tcl: Allow ports to override configure.cxx_stdlib

See #55382

[ryandesign (Ryan Carsten Schmidt)]

In 05b30256b14009357ea9c9b94511bfa00e727571/macports-ports:

cxx11-1.1.tcl: Use gcc6 on Leopard and earlier

PowerPC machines were already doing so, but Intel machines need to as
well because libcxx and related ports enforce the universal variant,
and the default universal_archs on Leopard and earlier include ppc.

See #55382
See #55442

[ryandesign (Ryan Carsten Schmidt)]

In fcaeca417b5d60413f106f01c11dda06749c867b/macports-ports:

cmake: Force libc++ on Snow Leopard and newer

This does not cause problems on libstdc++ systems because cmake doesn't
depend on any C++ libraries, nor does it supply any C++ libraries.

This fixes the build on Mac OS X 10.6-10.8.

On Lion, force the use of macports-clang-3.4, which contains a fix for
a Lion-specific libc++ bug. The fix appears not to be present in
macports-clang-3.7 which is the compiler that would otherwise be used.

On Leopard and earlier, use the cxx11-1.1 portgroup's default behavior
of using gcc6 and its libstdc++.

Closes: #55382

[fvaccari]

I confirm that all works now on 10.7.5 here. Thanks for the huge coordinated work!

[thetrial (alabay)]

The fix managed that macports now works with OSX 10.7.5, thanks a lot.

Now I have clang-3.4, 3.7, 3.8, 3.9, 4.0 and 5.0 and the corresponding llvm-3.4…5.0 on my system. So what is necessary and what could be uninstalled? Would it be right to set 5.0 requested and let the rest go?

What makes me wonder a bit:

The following ports are dependent on llvm-3.4:
  cctools
    libgcc
  clang-3.4
  ld64-latest
    ld64
      clang-3.7
      clang-3.8
      clang-3.9
      clang-4.0
      clang-5.0

So what is the right way to go now?

[ryandesign (Ryan Carsten Schmidt)]

Replying to thetrial:

Now I have clang-3.4, 3.7, 3.8, 3.9, 4.0 and 5.0 and the corresponding llvm-3.4…5.0 on my system. So what is necessary and what could be uninstalled? Would it be right to set 5.0 requested and let the rest go?

You can sudo port uninstall leaves to uninstall ports that you did not request and that are not needed. But MacPorts will reinstall them later if they are needed when you ask to install something else later.'

Marking clang-5.0 (or any other port) as requested will have no effect on whether MacPorts needs to use that port to build another port, though it will remove it from the list of leaves.

[thetrial (alabay)]

But are so many different compilers plus stuff necessary? I remember that they all got installed via two days and one night, so it takes really long to build them. But is such a chain necessary? If I’s simply uninstall all leaves no mp-compiler would rest. So I’m not sure how to act. So what compiler is needed? And is another compiler needed for this one to be built?

[ryandesign (Ryan Carsten Schmidt)]

I don't have a good answer for you at this time, other than MacPorts installed them for you because it thought it needed them to build a port you asked it to build. It may be possible to reduce the number of compilers needed, but I don't know specifically what would need to be done to accomplish that. Resolving #55444 may help. Further adjustments to the MacPorts base compiler fallback list may be needed. One change was already made there and not yet backported to MacPorts 2.4.x; I've ​suggested we backport that and release a new version of 2.4.x.

[RJVB (René Bertin)]

This reeks like it might be related to #53201. Cmake builds via a bootstrap procedure after all.
(I no longer have easy access to a pre-10.9 system so cannot simply test for myself to what extent this is true AND relevant for the issue at hand.)

[kencu (Ken)]

As time went by, I have them all too -- and more

  clang-3.4 @3.4.2_12+analyzer+arm_runtime+universal (active) platform='darwin 10' archs='i386 x86_64' date='2016-11-02T18:55:48-0700'
  clang-3.6 @3.6.2_5+analyzer+universal platform='darwin 10' archs='i386 x86_64' date='2016-11-03T01:59:03-0700'
  clang-3.7 @3.7.1_5+analyzer+universal (active) platform='darwin 10' archs='i386 x86_64' date='2016-12-26T05:44:03-0800'
  clang-3.8 @3.8.1_9+analyzer+libstdcxx (active) platform='darwin 10' archs='x86_64' date='2017-12-01T19:53:23-0800'
  clang-3.9 @3.9.1_7+analyzer+forcelibcxx+libstdcxx (active) platform='darwin 10' archs='x86_64' date='2017-10-22T12:28:47-0700'
  clang-4.0 @4.0.0_0+analyzer+libstdcxx (active) platform='darwin 10' archs='x86_64' date='2017-07-01T20:20:28-0700'
  clang-5.0 @5.0.0_5+analyzer+libstdcxx+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-12-11T03:17:47-0800'

My advice would be to just leave them. It is somewhat inefficient, to be sure. However, the various ports that called these in are often written to specific compiler/llvm setups. Sometimes things build with one but not with another. There are idiosyncracies, many of which will probably never be resolved on these old systems.

I consider it a price to be paid to keep these 10+ year old systems working.