[MacPorts] #65415: libgcc9 @9.5.0_1: builds fail on 10.8, 10.9, 10.10

[MacPorts]

#65415: libgcc9 @9.5.0_1: builds fail on 10.8, 10.9, 10.10
-----------------------+------------------------
  Reporter:  chillin-  |      Owner:  i0ntempest
      Type:  defect    |     Status:  closed
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.7.2
Resolution:  fixed     |   Keywords:
      Port:  libgcc9   |
-----------------------+------------------------

Comment (by mascguy):

 There's no flaming going on here, I'm simply trying to educate. And this
 is all good, positive discussion!

 So here's the bottom line: The JVM compiles Java pcode into true native
 code - highly-optimized code, comparable to the best C/C++ compilers - and
 then runs that native code at full speed. In short, there isn't any
 interpretation, beyond the first few seconds of execution. After that,
 it's all native code, which is how it's matches or beats C/C++
 performance.

 As for garbage collection: In the very early days of the industry - before
 the days of multi-core CPUs, when speeds were still measured in MHz - GC
 did have a tangible impact on performance. And it could be quite
 intrusive, depending on the language/system.

 Since then, GC techniques have evolved so far, that they're actually more
 efficient than C code that explicitly calls malloc() and free(). (Or the
 `new` and `delete` operators in C++, if you prefer.) That's because memory
 deallocation and reclamation can occur in the background - and in a
 batched, highly-efficient manner - such that it's inconsequential.

 That's why even the newest languages like Google's Go - which was designed
 from the ground up as a C/C++ replacement - use GC for memory management.
 It's really that good!

 All that said, if there's a legitimate concern - like `pdftk-java` not
 being as mature and reliable - then that's certainly reasonable.

 Anyhow, I'm not trying to sell you on Java per se. Rather, I'm simply
 suggesting that you try to keep an open mind, and don't reject a solution
 simply because it's not pure C/C++.

 Does that make sense?

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