What's the right way to build on OSX with existing xcode 11.6 toolchain?
asyncify opened this issue · 8 comments
Hi, I'm pretty psyched to try this out so first have some questions around building. Rather than install specific gcc/g++/llvm, can the build work with those tools that come with XCode? I'd like to avoid having projects with different toolchains if it's easy. For XCode 11.6 that appears to be:
llvm-g++ --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
But naively exporting LLVM_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain doesn't help my cmake . command:
cmake .
CMake Error at CMakeLists.txt:17 (find_package):
Could not find a package configuration file provided by "LLVM" with any of
the following names:
LLVMConfig.cmake
llvm-config.cmake
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.
...
Is there an easy way to make this all work together? Thanks!
Awesome! It's always great to hear from people who are interested in experimenting with these ideas. :)
Unfortunately it looks like XCode doesn't include the LLVM backend libraries, which is what hobbes needs to JIT compile machine code.
You probably can use your existing compiler toolchain to compile everything, but you'll need to get the LLVM dependency to build it. I wish I could convince them to include the LLVM backend libraries with XCode, I definitely would.
This has been the hardest part of getting started with hobbes for everyone. I started an alternative backend a while back, but haven't had the time to replace LLVM with it.
Thanks for your quick response, I'd much prefer you build on LLVM so all good.
I will install llvm via brew -- I know your main README says LLVM 3.3 and greater, but is there a known latest that has been verified to work? I've seen issues raised regarding llvm@6.
Update: with llvm@8 I think I have everything that's needed, 'cmake .' completes successfully, but unfortunately it's not finding an include that is quite obviously there in $LLVM_DIR/include. Normally I'd just find the appropriate makefile and add that to the include directories, but I have no idea how to achieve that here:
asyncify% make
[ 1%] Building CXX object CMakeFiles/hobbes.dir/lib/hobbes/boot/gen/boot.C.o
...
hobbes/include/hobbes/util/llvm.H:36:10: fatal error:
'llvm/Bitcode/ReaderWriter.h' file not found
#include <llvm/Bitcode/ReaderWriter.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Apologies, not sure what I've done wrong here ...
That sounds like a breaking LLVM change. Could you try with llvm@6? That's what our automated builds on macOS (via travis-ci) are using at least, so should at least get you in a state where you can try some things out.
I will give that a try, although I confess everything looks to be fine in all the generated flags.make files:
CXX_INCLUDES = -I/usr/local/opt/readline/include -I/usr/local/opt/llvm\@8/Toolchains/LLVM8.0.1.xctoolchain/usr/include -I/Users/asyncify/github/hobbes/include
It might be of note that there were two options for LLVMConfig.cmake, I guess for GCC toolchain or xcode toolchain:
/usr/local/opt/llvm\@8/Toolchains/LLVM8.0.1.xctoolchain/usr/include
/usr/local/opt/llvm@8/lib/cmake/llvm
Tried both with the same result, not finding the LLMV includes.
..... but hey, what do I know? llvm@6 built without a single error and I've got the shell up and running.
Thanks for your help!
Yeah the problem is that LLVM constantly makes breaking changes, and it's pretty annoying to constantly chase those issues down and basically get nothing for it on the other side (in fact, in some cases we've seen JIT performance regression on later LLVMs).
The header-only backend that I made (in include/hobbes/mc/) is a basic backend for x86_64, does register allocation and instruction encoding, but for some use-cases for hobbes it could be a performance regression to swap it in place of LLVM, since we do rely on LLVM's backend optimizations in a few areas.