[MacPorts] #54370: gmic @2.0.2: buildbot build gets cancelled because 20 minutes go by with no output

[MacPorts]

#54370: gmic @2.0.2: buildbot build gets cancelled because 20 minutes go by with no
output
-------------------------+-------------------------
  Reporter:  ryandesign  |      Owner:  Schamschula
      Type:  defect      |     Status:  reopened
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  haspatch
      Port:  gmic        |
-------------------------+-------------------------

Comment (by ryandesign):

 I gave the 10.8 buildbot worker 12 GB RAM and started a gmic build. When
 the clang process reached around 10 GB RAM usage, it started eating up
 gigabytes of swap and I canceled the build and rebooted the worker with 18
 GB RAM and started a new build. This time the clang process reached 15.74
 GB before it started hitting the swap space. I saw the clang process use
 as much as 15.99 GB RAM and 6 GB swap. The build has been going for 53
 minutes but I expect it to fail because:

 I gave the 10.9 worker 15 GB RAM and I observed the clang process using
 12.47 GB at its peak. The build was canceled after 1 hour 58 minutes
 because of no output seen for 1 hour.

 The gmic developers closed [https://github.com/dtschump/gmic/issues/325 my
 bug report] with the opinion that the clang compiler is flawed and that
 they will not make any accommodations for it. They say that old versions
 of g++ had similar problems but that new versions don't. They suggest that
 compiling without optimization flags may reduce memory usage.

 Trying to compile gmic using g++ would require that g++ supports
 `-stdlib=libc++`. Did that
 [https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-libcpp-LLVM-
 Support make it into gcc11] or is it coming for gcc12? I don't think
 MacPorts base knows that any g++ supports `-stdlib` yet so until then it
 would have to be manually added by the Portfile.

 Our builds on newer OS versions have already completed so I don't know if
 newer clangs use less memory. Perhaps someone on macOS 12 could check how
 much memory clang ends up using during the build. If it's considerably
 less, then maybe making the port use a newer MacPorts clang is the answer.
 And I think it may be. While build times are not a great indicator, since
 different VMs are on different servers with different loads, here's the
 latest build times:

 * 10.6 i386: MacPorts clang 11: 42 minutes
 * 10.6 x86_64: MacPorts clang 11: 46 minutes
 * 10.7: MacPorts clang 12: 51 minutes
 * **10.8: Xcode 5.1.1 clang 503.0.40: failed after an hour**
 * **10.9: Xcode 6.2 clang 600.0.57: failed after an hour (the retry with
 15 GB RAM failed after 1 hour 58)**
 * **10.10: Xcode 7.2.1 clang 700.1.81: failed after an hour**
 * **10.11: Xcode 8.2.1 clang 800.0.42.1: 1 hour 58 minutes**
 * **10.12: Xcode 9.2 clang 900.0.39.2: 1 hour 27 minutes**
 * 10.13: Xcode 9.4.1 clang 902.0.39.2: 42 minutes
 * 10.14: Xcode 10.3 clang 1001.0.46.4: 49 minutes
 * 10.15: Xcode 11.7 clang 1103.0.32.62: 34 minutes
 * 11 x86_64: Xcode 12.5.1 clang 1205.0.22.11: 33 minutes
 * 12 x86_64: Xcode 13.1 clang 1300.0.29.3: 46 minutes

 So what would you think about blacklisting `{clang < 902}`?

-- 
Ticket URL: <https://trac.macports.org/ticket/54370#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS