[MacPorts] #60291: clang-devel @devel-r365158_1+analyzer+assertions+libstdcxx re-build failure

MacPorts noreply at macports.org
Fri Apr 3 02:49:59 UTC 2020


#60291: clang-devel @devel-r365158_1+analyzer+assertions+libstdcxx re-build failure
--------------------------+----------------------
  Reporter:  cave-canem   |      Owner:  jeremyhu
      Type:  defect       |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.6.99
Resolution:  worksforme   |   Keywords:
      Port:  clang-devel  |
--------------------------+----------------------

Comment (by kencu):

 "Link Time Optimization". Basically clang compiles all the source code
 into LLVM bitcode instead of into actual machine language object files.
 Then, at the end, in the link stage, the linker (ld64) will then pass all
 that bitcode from all the different objects and libraries through
 optimization passes in llvm, and then finally the optimized llvm bitcode
 final product with be sent to the assembly writer modules to be finaly
 made into a real executable file.

 But when clang-9.0 takes a bunch of source code and compiles it into llvm
 bitcode, then it gets sent to an older ld64 such as you are using that is
 linked against an even older llvm (3.7) to do the final optimization
 stages -- well frankly I'm surprised it actually ever works.

 I usually upgrade my ld64 to the latest possible version (ld64-latest runs
 on 10.6.8 and up) and I build it against the latest llvm that we have
 available (currently llvm-9.0) and I also use cctools that is likewise
 linked against the latest llvm we have, all with the idea that it will
 minimize this sort of thing.

 Probably we should all do that -- the +llvm37 variants of things should
 all be "+bootstrap" variants that have to be upgraded before actually
 being used.

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


More information about the macports-tickets mailing list