How to run LLVM3.6.1 on OS X (Yosemite, Xcode6.4) OR how to link bitcode generated by OS X clang with LLVM3.6.1

I’m developing a Common Lisp compiler for OS X and Linux that uses LLVM as its backend and interoperates with C++.
It’s at: github.com/drmeister/clang

I need to compile one C++ source file containing small, intrinsic functions into an LLVM-IR bitcode file and link it with bitcode generated by my compiler running LLVM3.6.1. I have been unable to do this for more than a year and I was hoping that Apple would catch up.

If anyone has suggestions on how to do one of the following - I would greatly appreciate it.
1) Running clang built using LLVM3.6.1 (or higher) on OS X doesn’t work because it doesn’t find system header files.
I’ve added "-resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0” to the command line and while versions of this path have worked in the past - it doesn’t work anymore.

2) Using the version of clang provided by Xcode6.4 generates a bitcode file but it cannot be loaded into my language that was compiled using LLVM3.6.1. It complains with the following message:
Linking app-resources:lib;release;intrinsics_bitcode_boehm.o
warning: ignoring debug info with an invalid version (602053001) in /Users/meister/Development/clasp/build/clasp/Contents/Resources/lib/release/intrinsics_bitcode_boehm.o
warning: Linking two modules of different target triples: /Users/meister/Development/clasp/build/clasp/Contents/Resources/lib/release/intrinsics_bitcode_boehm.o' is 'x86_64-apple-macosx10.7.0' whereas 'image' is 'x86_64-apple-macosx10.9.4'

warning: linking module flags 'Debug Info Version': IDs have conflicting values
Running link time optimization module pass manager
Generating object file /Users/meister/Development/clasp/src/lisp/build/system/full-boehm/image.lbc --> /Users/meister/Development/clasp/src/lisp/build/system/full-boehm/image.o reloc-model: RELOC-MODEL-DEFAULT

I always thought that this was just a warning but now that I look at the resulting bitcode file after linking I see that no inlining of the functions in intrinsics_bitcode_boehm.o (this is a bitcode file and not a .o file as the extension suggests) is taking place.

If anyone has suggestions on how to (1) compile C++ code with LLVM3.6.1 on OS X or (2) generate bitcode from C++ using the builtin clang on OS X that can be read by LLVM3.6.1 I’d greatly appreciate it.

Best,

.Chris.

If anyone has suggestions on how to do one of the following - I would greatly appreciate it.
1) Running clang built using LLVM3.6.1 (or higher) on OS X doesn’t work because it doesn’t find system header files.
I’ve added "-resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0” to the command line and while versions of this path have worked in the past - it doesn’t work anymore.

Resource-dir specifies the compiler's really, really internal support
bits. It definitely has to match the compiler being used rather than
the one provided with Xcode. What you probably want to play with
instead is -isysroot, though an OSS clang may or may not be able to
interpret those headers at any given point in time.

I always thought that this was just a warning but now that I look at the resulting bitcode file after linking I see that no inlining of the functions in intrinsics_bitcode_boehm.o (this is a bitcode file and not a .o file as the extension suggests) is taking place.

They look like reasonably harmless warnings to me too. The true test
of whether it's worked is going to be whether the output file runs
correctly though, rather than whether LLVM decided any particular
optimisation was profitable.

I assume you're running optimisation passes after linking the two
modules together? Perhaps try looking into the inliner to see why it's
decided not to do that one.

Cheers.

Tim.

Thank you. I found a partial answer to the problem (1), namely “how to run Clang compiled with LLVM3.6.1 on OS X Yosemite/Xcode6.4"
It’s a combination of -isysroot and -resource-dir

I’m using these compiler options:

"/Users/meister/Development/externals-clasp/build/release/bin/clang" -v \
    -resource-dir "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0" \
    -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk \

I say partial answer because when I try to compile all of my C++ source files some headers are still not found. But the one source file that I need to compile to generate llvm bitcode now works.

The search paths that are searched with these options are:

../../include
../../src
../../src/llvmo
/Users/meister/Development/externals-clasp/build/common/include
/Users/meister/Development/externals-clasp/build/release/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks (framework directory)
End of search list.

When I compile with /usr/bin/clang -v it reports these search paths:

../../include
../../src
../../src/llvmo
/Users/meister/Development/externals-clasp/build/common/include
/Users/meister/Development/externals-clasp/build/release/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks (framework directory)
End of search list.

Which are essentially the same except /usr/bin/clang also searches: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include

If anyone has suggestions on how to do one of the following - I would greatly appreciate it.
1) Running clang built using LLVM3.6.1 (or higher) on OS X doesn’t work because it doesn’t find system header files.
I’ve added "-resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0” to the command line and while versions of this path have worked in the past - it doesn’t work anymore.

Resource-dir specifies the compiler's really, really internal support
bits. It definitely has to match the compiler being used rather than
the one provided with Xcode. What you probably want to play with
instead is -isysroot, though an OSS clang may or may not be able to
interpret those headers at any given point in time.

Do you know what you would set “-isysroot” to on OS X to get clang3.6.1 to run on OS X?

"/Users/meister/Development/externals-clasp/build/release/bin/clang" -v \
    -resource-dir "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0" \

I still think this is asking for trouble. It might help clang to find
the libc++ headers (iostream etc, under ../../../include/c++/v1), but
you're also providing it incorrect copies of its internal headers. A
better way is to either build libc++ with your Clang or symlink
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
into your compiler's real resource hierarchy. (I usually symlink,
myself).

I say partial answer because when I try to compile all of my C++ source files some headers are still not found.

Which headers are missing? I'd hope anything critical in
XcodeDefault.xctoolchain/usr/include could be provided by your own
built clang.

Do you know what you would set “-isysroot” to on OS X to get clang3.6.1 to run on OS X?

I think you got it right with the SDK path you used above:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk

(modified for the actual SDK version you have installed).

Cheers.

Tim.

Tim,

I am getting trouble.

Could you provide a bit more detail on where to symlink /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 into?
I’m not sure where my compiler’s real resource hierarchy is.

"/Users/meister/Development/externals-clasp/build/release/bin/clang" -v \
   -resource-dir "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0" \

I still think this is asking for trouble. It might help clang to find
the libc++ headers (iostream etc, under ../../../include/c++/v1), but
you're also providing it incorrect copies of its internal headers. A
better way is to either build libc++ with your Clang or symlink
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
into your compiler's real resource hierarchy. (I usually symlink,
myself).

I say partial answer because when I try to compile all of my C++ source files some headers are still not found.

Which headers are missing? I'd hope anything critical in
XcodeDefault.xctoolchain/usr/include could be provided by your own
built clang.

I think this is the trouble that I’m asking for above.

Could you provide a bit more detail on where to symlink /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 into?
I’m not sure where my compiler’s real resource hierarchy is.

If you've run "make install" I believe it's in $PREFIX/lib/clang/3.6.1
(or whatever version you're using), so by default it would be
/usr/local/lib/clang/3.6.1. Then you'd link c++ to $PREFIX/include/c++
and the headers should be found.

If you used MacPorts or similar, it ought to be able to tell you which
files it created; just look for a "3.6.1" directory and that'll
probably be the one you want.

Cheers.

Tim.