llvm dev - Jul 2015 - [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

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

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