ccache @4.13.1_0+doc: no member named 'ranges' in namespace 'std'

[thetrial (alabay)]

When trying to build under Sierra:

/opt/local/var/macports/build/ccache-71117637/work/ccache-4.13.1/src/ccache/config.cpp:87:15: error: no member named 'ranges' in namespace 'std'
:info:build   return std::ranges::any_of(safe_dirs, [&](const auto& safe_dir) {
:info:build          ~~~~~^
:info:build 1 error generated.
:info:build make[2]: *** [src/ccache/CMakeFiles/ccache_framework.dir/config.cpp.o] Error 1
:info:build make[2]: *** Waiting for unfinished jobs....
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/ccache-71117637/work/build'
:info:build make[1]: *** [src/ccache/CMakeFiles/ccache_framework.dir/all] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/ccache-71117637/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/ccache-71117637/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/ccache-71117637/work/build" && /usr/bin/make -j24 -w all VERBOSE=ON 
:info:build Exit code: 2
:error:build Failed to build ccache: command execution failed

[aeiouaeiouaeiouaeiouaeiouaeiou]

The same thing happens with the build on Mountain Lion. Ccache version 4.13 now requires the C++20 standard, and to ensure that such code runs on older systems, a newer version of libc++ from the legacysupport portgroup is used.

Unfortunately, this version of libc++ is based on LLVM 11 (for ABI compatibility), whereas the core functionality of std::ranges was ​only added in LLVM 13.

A similar issue broke bitcoin portfile on older versions of macOS two years ago (and has still not been resolved): #69805

I think it’s worth applying the solution suggested by Tomio Arisaka here as well: comment:ticket:73454:23

I'll try to check that later; right now, I need to get some sleep.

[aeiouaeiouaeiouaeiouaeiouaeiou]

Replying to aeiouaeiouaeiouaeiouaeiouaeiou:

I think it’s worth applying the solution suggested by Tomio Arisaka here as well: comment:ticket:73454:23

...and it worked.

Still, it's a pretty messy solution.

[reneeotten (Renee Otten)]

I don't think we should be starting to add that type of workaround to Portfiles. If people are interested in keeping older systems supported then I suppose someone should be working on updating the macports-libcxx port instead.

[thetrial (alabay)]

Abandon?

[Dave-Allured (Dave Allured)]

Abandon?

No. macports-libcxx is being worked on over here: ​https://github.com/macports/macports-ports/pull/31641

[rmottola (Riccardo)]

I tried building with GCC but I get the same error on std::ranges. Is tis because gcc is bein forced to use the same libcxx instead of its own? To avoid issues like we see on poppler?

[ryandesign (Ryan Carsten Schmidt)]

You can't use g++ with its libstdc++ to build because that wouldn't be compatible with all the other C++ ports that use libc++. All C++ software that wants to play together must use the same standard library family.

Recent g++ can use libc++ but I don't know how well that works and you can't use g++ with the system's libc++ because, just like when using clang++ with the system's libc++, the system's libc++ isn't new enough.

You could presumably use clang++ (or maybe g++) with a newer libc++ from the macports-libcxx port, once it's been updated to a new enough version.

You could presumably use clang++ (or maybe g++) with a newer libc++ from an llvm port, somehow.

I agree it would be good to have a general solution to this problem that any port can use, rather than trying to copy/paste a bunch of confusing code into each port.

[kencu (Ken)]

Hey Riccardo, how are you?

I have a little present for you, which is an implementation of the fix I proposed for this issue 3 weeks ago comment:ticket:74078:12. I just couldn't stop myself from doing it for you.

--- legacysupport-1.1.tcl.orig	2026-06-24 23:24:30.000000000 -0700
+++ legacysupport-1.1.tcl	2026-06-24 23:50:54.000000000 -0700
@@ -38,6 +38,10 @@
 options legacysupport.use_mp_libcxx
 default legacysupport.use_mp_libcxx     no
 
+# use the headers installed by the macports-libcxx port or the compiler's headers
+options legacysupport.use_mp_libcxx_headers
+default legacysupport.use_mp_libcxx_headers     yes
+
 options legacysupport.disable_function_wrap
 default legacysupport.disable_function_wrap no
 
@@ -171,9 +175,15 @@
         # Flags for using MP libcxx
         if { [option legacysupport.use_mp_libcxx] && ${configure.cxx_stdlib} eq "libc++" } {
             legacysupport::add_once depends_lib append port:macports-libcxx
-            append ls_cache_incpath  " ${prefix}/include/libcxx/v1"
             append ls_cache_ldflags  " -L${prefix}/lib/libcxx"
-            append ls_cache_cppflags " -nostdinc++ -isystem${prefix}/include/libcxx/v1"
+
+            # use the headers installed by the macports-libcxx port or the compiler's headers
+            if {[option legacysupport.use_mp_libcxx_headers]} {
+                append ls_cache_cppflags " -nostdinc++ -isystem${prefix}/include/libcxx/v1"
+                append ls_cache_incpath  " ${prefix}/include/libcxx/v1"
+            } else {
+                append ls_cache_cppflags " -D_LIBCPP_DISABLE_AVAILABILITY"
+            }
         }
 
         ui_debug "legacysupport: ldflags  ${ls_cache_ldflags}"

and then to use the compiler's headers instead of the older macports-libcxx headers, add this to the porfile of the port that shows this ranges issue:

legacysupport.use_mp_libcxx_headers     no

NB this is not a super-robust fix. I proposed better fixes here: comment:ticket:74078:48, especially options 3 and 4. But those are perhaps more complicated, and this fix is absolutely trivial to implement.

$ port -v installed ccache libheif
The following ports are currently installed:
  ccache @4.7.4_1+doc requested_variants='' platform='darwin 11' archs='x86_64' date='2022-12-21T09:08:40-0800'
  ccache @4.13.1_0+doc (active) requested_variants='' platform='darwin 11' archs='x86_64' date='2026-06-25T00:11:44-0700'
  libheif @1.13.0_0 requested_variants='' platform='darwin 11' archs='x86_64' date='2022-09-04T19:00:54-0700'
  libheif @1.13.0_1 requested_variants='' platform='darwin 11' archs='x86_64' date='2023-01-08T11:53:31-0800'
  libheif @1.23.0_0+examples+kvazaar (active) requested_variants='' platform='darwin 11' archs='x86_64' date='2026-06-24T23:57:44-0700'

[rmottola (Riccardo)]

@kencu Hi! good to know you around. I'm quite fine. Up-and-downs, was active on other projects and just "used" MacPorts without tinkering with it. I finally wanted to test your "quick fix" (which looks a bit scary to have differing headers from library) but my legacysupport port file looks very different, the patch cannot apply. DO you have a different one? mine is

legacy-support

legacy-support @1.5.2_0 (active)

[kencu (Ken)]

The patch was generated against the legacysupport-1.1 PortGroup file.

[thetrial (alabay)]

Today I tried again … still the same error. So the patch is not implemented yet?

[lucasaccarola]

Hi there, same issue after a "selfupdate" from a working 2.11.6 to 2.12.6 on macOS v10.13.6. Can you tell me where I can get the above mentioned patch ? Do I need to reinstall MP via GIT to use the development version, or what else ? TIA