On 7/5/21 6:34 PM, Taylor Simpson wrote: > Signed-off-by: Taylor Simpson <tsimp...@quicinc.com> > --- > target/hexagon/README | 83 > ++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 82 insertions(+), 1 deletion(-)
I'm poking at the hexagon toolchain build script you checked into the test directory, which boils down to (starting with): git clone https://github.com/llvm/llvm-project mkdir build-llvm cd build-llvm cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=$(readlink -f ../llvm) -DLLVM_ENABLE_LLD=ON \ -DLLVM_TARGETS_TO_BUILD="Hexagon" -DLLVM_ENABLE_PROJECTS="clang;lld" \ $(readlink -f ../llvm-project/llvm) Except the LLVM_ENABLE_LLD part breaks with a standard debian/devuan x86-64 host toolchain because it ONLY works with host llvm, and apparently only a pretty current one at that: https://github.com/tensorflow/mlir-hlo/issues/4 (Devuan Beowulf only packages lld-7, not lld-10.) I'm currently building: cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=$(readlink -f ../llvm) -DLLVM_ENABLE_PROJECTS="lld" \ $(readlink -f ../llvm-project/llvm) ninja all install On the theory that should give me an lld-git I can play $PATH games and re-run the other build with, but my QUESTION is what does the LLVM_ENABLE_LLD=potato actually accomplish here? Is it a sanitizing step or is there something about building with gcc's lld that's known to break the hexagon toolchain? If I just omit it (to avoid building lld _twice_) will I (probably) get a working hexagon toolchain? (Assuming I do the musl and headers-install builds and so on?) What's the _issue_ here that this config symbol addresses? Thanks, Rob