> -----Original Message----- > From: Rob Landley <r...@landley.net> > Sent: Monday, July 12, 2021 3:16 AM ... > 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.)
Sorry about that, we did test only with fairly current/recent lld. > 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? lld is not necessary to build the hexagon toolchain. It just happens that the build process takes an enormous amount of time (and memory) using the gnu BFD ld. I would expect building with either ld/gold would work fine. If you don't mind binaries, there are x86_64 linux binary toolchains with lld on releases.llvm.org and there's also a binary hexagon-linux cross toolchain that we shared for use by kernel developers. The hexagon linux toolchain is built on Ubuntu 16.04. But when building your toolchain, omitting LLVM_ENABLE_LLD should work just fine. -Brian