[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