[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
Wed, 08 Jul 2015 00:14:08 -0000

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.