[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

[Christian Schafmeister]

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