[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 chillin-):

 >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 matches or beats C/C++ performance.

 p-code, or bytecode, is an intermediary between the Java language and the
 processor's native machine code. Modern C++ compilers typically compile to
 native machine code, though sometimes assembly is used as an intermediate
 step, but assembly is effectively human readable machine code. p-code is
 not human readable, and the code is interpreted on the JVM which itself
 runs on the processor. Java may be matching or exceeding performance of
 C++ native binaries, but it can't do so running on the bare metal without
 a JVM.


 > As for garbage collection

 Java requires it, C++ doesn't need it. pdftk, as an example, will
 necessarily require less memory than pdftk-java.


 >That's why even the newest languages like Google's Go - which was
 designed from the ground up as a C/C++ replacement

 This is contradictory. If it was designed as a replacement for C++, then
 C++ actually was the ground. For whatever reasons (my understanding is it
 was due to frequent version incompatibilities), Ken Thompson hated C++
 from its early development (probably couldn't tolerate writing something
 more than once). That is why he co-developed Go, a reaction to C++, which
 is not a replacement for C++ as it doesn'r support direct calling of
 functions written in C/C++, and these languages are too engrained. One
 man's (well, three men's) intolerance for C++ is not a compelling reason
 to replace C++, and there are no other compelling reasons that could whelm
 me, as I am not a developer. Nevertheless, discussion of Go here is
 somewhat of a straw man.

 >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++.

 I'm not a developer, only at times a lowly sysadmin. When a solution is
 not immediately forthcoming, I'll use whatever works, no matter how ugly
 it may be. Fortunately, I already have something that works just fine with
 only a trivial adjustment to my upgrade script to get the best package
 manager in the world to cooperate.


 >Does that make sense?

 I don't think you really want to know.

 ---

 >with a little bit of manual effort I can show you how to have it... Let
 me know if that interests you.

 That is incredibly generous, and appreciated, but I assure you it is not
 necessary. I'd honestly prefer the pdftk binary I rolled myself (with all
 the heavy lifting by MacPorts), which fortunately happens to already be
 installed on the system and which I briefly used earlier today to combine
 some pdfs that I wanted bundled together. I don't mind that pdftk is no
 longer in active development, and I honestly believe that most software
 would benefit from that strategy rather than continue endlessly on the
 death march of feature creep, which ruins so much good software it is
 ridiculous -for me personally and most recently, my iPad's ssh client. I
 want back the way it worked 2 years ago, but the developers insist it had
 rendering artifacts, which I never personally experienced and think
 they're making it up.

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