Compiling on Mac gave me more issues than I expected with linking to LibClang. I'm not sure if this is the fault of my specific setup, a Cmake quirk, the Ventura update, or just xcode structure.
Walkthrough of the problem:
Building this project on MacOS Ventura on master at the time of writing this errors out when trying to build the icg target with:
ICG/include/utils.hpp:3:10: fatal error: 'clang-c/Index.h' file not found
This is strange because this file lives in /usr/local/include for me according to llvm-config --includedir, and this directory is included in the system path. Even manually adding /usr/local/include as an include directory to the icg target path did not resolve this, and I verified that the required file was there.
After digging into the generated build files, it looks like something (cmake? xcode?) automatically adds to CXX_FLAGS: -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk, which changes lookups that start from the root to instead start from that directory. Therefore, when I add /usr/local/include to the include directories, it looks under that directory instead, which does not include the Clang libraries. I'm not sure how to include them there (xcode is giving me so many headaches recently). My understanding is that MacOS uses this to implement an SDK for C++ stuff. Seems like a bad design choice to me, but maybe I just need to get with the times and just stop using system level installs.
When I instead used a path to a cloned LLVM install, or even the homebrew install, then the compiler was able to find clang-c/Index.h. Linking to the libclang library gave a similar issue which I could the resolve in the same way. It seems like using user-level installs may be the way to go in new MacOS versions.
This seems like it might be related to an issue that Trick deals with on MacOS. Trick requires the user to specify the path to LLVM at configure time (but for a slightly different reason, but I think that requiring the path to be specified actually solves this problem as a side effect). Therefore, the solution is probably just to force the user to give a path to the LLVM root at configure time here too.
There's a secondary problem here too - apparently we need to also pass the SDK flags into the compiler invocation in LibClang as well, otherwise it can't find the system c++ headers and doesn't know what to do with things like strings. I got a working solution patched together by manually passing in the compiler flags:
Compiling on Mac gave me more issues than I expected with linking to LibClang. I'm not sure if this is the fault of my specific setup, a Cmake quirk, the Ventura update, or just xcode structure.
Walkthrough of the problem:
Building this project on MacOS Ventura on master at the time of writing this errors out when trying to build the
icgtarget with:ICG/include/utils.hpp:3:10: fatal error: 'clang-c/Index.h' file not foundThis is strange because this file lives in
/usr/local/includefor me according tollvm-config --includedir, and this directory is included in the system path. Even manually adding/usr/local/includeas an include directory to theicgtarget path did not resolve this, and I verified that the required file was there.After digging into the generated build files, it looks like something (cmake? xcode?) automatically adds to CXX_FLAGS:
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk, which changes lookups that start from the root to instead start from that directory. Therefore, when I add/usr/local/includeto the include directories, it looks under that directory instead, which does not include the Clang libraries. I'm not sure how to include them there (xcode is giving me so many headaches recently). My understanding is that MacOS uses this to implement an SDK for C++ stuff. Seems like a bad design choice to me, but maybe I just need to get with the times and just stop using system level installs.When I instead used a path to a cloned LLVM install, or even the homebrew install, then the compiler was able to find
clang-c/Index.h. Linking to the libclang library gave a similar issue which I could the resolve in the same way. It seems like using user-level installs may be the way to go in new MacOS versions.This seems like it might be related to an issue that Trick deals with on MacOS. Trick requires the user to specify the path to LLVM at configure time (but for a slightly different reason, but I think that requiring the path to be specified actually solves this problem as a side effect). Therefore, the solution is probably just to force the user to give a path to the LLVM root at configure time here too.
Here's another project that seems to be dealing with the same problem: https://github.com/Sarcasm/irony-mode/wiki/Mac-OS-X-issues-and-workaround
There's a secondary problem here too - apparently we need to also pass the SDK flags into the compiler invocation in LibClang as well, otherwise it can't find the system c++ headers and doesn't know what to do with things like strings. I got a working solution patched together by manually passing in the compiler flags:
But we're obviously going to have to figure out a more flexible way of dealing with this.
I'm putting this aside for now, but the branch macos-fixes currently builds on MacOS (or at least on my mac 😬 ).