Build on macOS

[gogins]

• Install llvm@13.
• Deal with caveats:

To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/opt/homebrew/opt/llvm/lib -Wl,-rpath,/opt/homebrew/opt/llvm/lib"

llvm is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have llvm first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/llvm/bin:$PATH"' >> ~/.zshrc

For compilers to find llvm you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/llvm/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/llvm/include"

• Update macOS build script.
• Test.

[gogins]

LLVM has moved the example I used out of https://github.com/llvm/llvm-project/tree/main/clang/examples/clang-interpreter and may have replaced it with https://github.com/llvm/llvm-project/blob/main/clang/unittests/Interpreter/InterpreterTest.cpp.

It was viewed as redundant with clang-repl: https://github.com/llvm/llvm-project/blob/main/clang/tools/clang-repl/ClangRepl.cpp. But I don't see that at all.

https://compiler-research.org/assets/presentations/L_Hames-CaaS_ORC_JitLink.pdf is current status of ORC.

https://github.com/llvm/llvm-project/tree/main/llvm/test/ExecutionEngine

These llvm issues may be relevant:

• regression: locally-built Clang can't find C++ stdlib headers on Mac llvm/llvm-project#45225.
• LLDB build failure on including stdlib llvm/llvm-project#52611.
• Compiler-provided inttypes.h is not recognized as belonging to any module llvm/llvm-project#50649, this sounds like my actual problem. I will verify whether this is my problem and, if so, try to work around it. I will not patch llvm. I will then file an issue.
• [llvm] default clang resource dir is incorrect microsoft/vcpkg#16284, may be related to just above.

.

[gogins]

Clang comes with a resource directory that contains vendor-specific include files like standard headers and inΩtrinsics definitions. As the contents is also specific for each version of Clang, it needs to be shipped with the executable. In a developer environment, however, it can easily be inferred from the LLVM/Clang build while configuring CMake...

[gogins]

I figured out the business with the resource directory and worked around it by explicitly setting it to be the same as when building the opcodes with the same clang-13 from Homebrew, but this did not fix the issue even though all the include paths in the compiler invocation now look correct.

There must be some other place in the toolchain where this is still a problem.

[gogins]

See https://weliveindetail.github.io/blog/post/2017/07/25/compile-with-clang-at-runtime-simple.html.

[gogins]

I submitted an issue to llvm but the developers first did not understand me, then more or less understood me but declined to fix the issue.

This of course is no help at all. I will replace the embedded compiler with opcodes that merely shell out, run a compiler, and dynamically load and invoke a compiled module.

[gogins]

A bit more help from the llvm developers. My surmise was correct but the suggested fix may not work. I am re-opening this issue just in case.

[gogins]

I am closing this issue, as using the system compiler works just fine; the actual invention in these opcodes is binding C++ objects compiled at run time to the Csound process, which works just the say for both embedded compilers and system compilers.