[LLVMdev] 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 (original) (raw)

Christian Schafmeister chris.schaf at verizon.net
Tue Jul 7 17:14:08 PDT 2015

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

On Jul 5, 2015, at 9:01 AM, Tim Northover <t.p.northover at gmail.com> wrote:

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?

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 intrinsicsbitcodeboehm.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.

More information about the llvm-dev mailing list