Can't build on OSX #4

jtravs · 2014-07-23T10:28:10Z

I tried to build following your mailing list instructions. However I get the following error during compilation of Julia itself:

In file included from /Users/john/Documents/code/downloaded/julia/deps/llvm-svn/tools/lldb/source/../include/lldb/Core/FormatNavigator.h:29:
/Users/john/Documents/code/downloaded/julia/deps/llvm-svn/tools/lldb/source/../include/lldb/Symbol/ClangASTContext.h:21:10: fatal error: 
      'llvm/ADT/OwningPtr.h' file not found
#include "llvm/ADT/OwningPtr.h"
         ^
1 error generated.

My Make.user:

USE_SYSTEM_LIBM=1
BUILD_LLVM_CLANG=1
BUILD_LLDB=1

My deps/Versions.make

USE_SYSTEM_LIBM=1
BUILD_LLVM_CLANG=1
BUILD_LLDB=1
...

I also merged the branches and applied the patch as stated on the mailing list.

In issue #3 a similar problem arose on Ubuntu, but I'm on OSX. Any ideas how I can solve this? How do I try "the master branch of lldb instead of release_33"

Apologies for the stupid questions.
I'm unreasonably excited about CXX.jl!
Thanks!

The text was updated successfully, but these errors were encountered:

ihnorton · 2014-07-23T12:10:34Z

How do I try "the master branch of lldb instead of release_33"

in /path/to/julia/:

echo "LLDB_VER = master" >> Make.user && make -C deps configure-llvm

or go to deps/llvm-svn/tools/lldb and git checkout master. Then run make install in llvm-svn/build_Release+Asserts.

acroy · 2014-07-23T12:59:47Z

I am on OSX 10.8.5 and got past the "llvm/ADT/OwningPtr.h" error, but now I am stuck with

llvm[8]: Compiling Host.cpp for Release+Asserts build
/Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/source/Host/common/Host.cpp:371:68: error: use of undeclared identifier 'CPU_SUBTYPE_X86_64_H'
                if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == CPU_SUBTYPE_X86_64_H)
                                                                   ^
1 error generated.

To get there at all I had to use

USECLANG=1
USE_LIBCPP=1

(not sure about USECLANG though) and I had to change "-mmacosx-version-min=10.6" to "-mmacosx-version-min=10.7" in deps/llvm-svn/build_Release+Asserts/Makefile.config (I am sure there is a better way to do this). I hope this makes some sense.

Any ideas how to proceed are greatly appreciated!

jtravs · 2014-07-23T13:19:17Z

Thanks @ihnorton that worked. I now also have the same issue as @acroy.

ihnorton · 2014-07-23T13:44:01Z

Depending on when you pulled the first time, something may have changed upstream in llvm. You should fetch and rebase to origin/master in llvm-svn and llvm-svn/tools/clang too, and then reconfigure and compile llvm. I don't think it should be necessary to edit any generated makefiles.

acroy · 2014-07-23T14:35:17Z

I agree that one shouldn't edit the makefiles, but I couldn't figure out how to change "10.6" to "10.7" properly. Without that I ran into the problem described here.

Anyways, I will try to fetch and rebase ...

ihnorton · 2014-07-23T14:44:26Z

This may go without saying or not be applicable, but just in case: "transitioning" an existing build from 3.3 to llvm-svn is a bad idea. It will be much better to do a separate clean build with the Make.user settings specified by Keno in place at the start of the build.

ihnorton · 2014-07-23T14:58:14Z

Hmm, sorry, I take that back. @Keno did not specify building Julia against LLVM master in the original email. (however, I know Keno does most of his work on llvm master so this may be more fully tested with that configuration).

Keno · 2014-07-23T15:30:07Z

@acroy I've seen that issue, I think it's a bug in lldb.

Try this:

diff --git a/source/Host/common/Host.cpp b/source/Host/common/Host.cpp
index 4aa362e..1519ff5 100644
--- a/source/Host/common/Host.cpp
+++ b/source/Host/common/Host.cpp
@@ -313,6 +313,8 @@ Host::SystemLog (SystemLogType type, const char *format, ...
     va_end (args);
 }

+#define CPU_SUBTYPE_X86_64_H 8
+
 const ArchSpec &
 Host::GetArchitecture (SystemDefaultArchitecture arch_kind)
 {

in the lldb sources

acroy · 2014-07-23T18:39:23Z

Thanks @Keno and @ihnorton. I did a completely fresh start (just to be sure) and Keno's patch got me past the "CPU_SUBTYPE_X86_64_H" issue. Now I am getting

In file included from /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/DNB.cpp:14:
In file included from /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/DNB.h:17:
In file included from /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/MacOSX/Genealogy.h:20:
In file included from /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/MacOSX/MachThreadList.h:17:
In file included from /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/MacOSX/MachThread.h:27:
/Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/tools/lldb/tools/debugserver/source/MacOSX/MachException.h:20:10: fatal error: 'DNBConfig.h' file not found
#include "DNBConfig.h"
         ^
1 error generated.
rm: /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/build_Release+Asserts/tools/lldb/tools/debugserver/source/Release+Asserts/DNB.d.tmp: No such file or directory

Keno · 2014-07-23T18:49:38Z

@acroy I've seen that one as well at times. I think there's a problem with make dependencies not being set up correctly. IIRC, the solution is to manually:

cd /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/build_Release+Asserts/tools/lldb/tools/debugserver/
make -C scripts

acroy · 2014-07-23T20:46:37Z

@Keno: You saved me once again! It goes almost through. I end up with

In file included from codegen.cpp:742:
./debuginfo.cpp:283:63: error: no matching function for call to 'createObjectFile'
            ErrorOr<llvm::object::ObjectFile*> origerrorobj = llvm::object::ObjectFile::createObjectFile(
                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/acr/Development/Julia/julia-cxx/usr/include/llvm/Object/ObjectFile.h:346:32: note: candidate function not viable: requires single argument 'ObjectPath',
      but 3 arguments were provided
  static ErrorOr<ObjectFile *> createObjectFile(StringRef ObjectPath);
                               ^
/Users/acr/Development/Julia/julia-cxx/usr/include/llvm/Object/ObjectFile.h:348:3: note: candidate function not viable: requires 2 arguments, but 3 were provided
  createObjectFile(std::unique_ptr<MemoryBuffer> &Object,
  ^
/Users/acr/Development/Julia/julia-cxx/usr/include/llvm/Object/ObjectFile.h:351:3: note: candidate function not viable: requires single argument 'Object', but 3
      arguments were provided
  createObjectFile(std::unique_ptr<MemoryBuffer> &Object) {
  ^

Keno · 2014-07-23T22:00:41Z

diff --git a/src/debuginfo.cpp b/src/debuginfo.cpp
index c79ba97..1886e59 100644
--- a/src/debuginfo.cpp
+++ b/src/debuginfo.cpp
@@ -279,17 +279,18 @@ void jl_getDylibFunctionInfo(const char **name, int *line, const char **filename
             // First find the uuid of the object file (we'll use this to make sure we find the
             // correct debug symbol file).
             uint8_t uuid[16], uuid2[16];
+
+            MemoryBuffer *membuf = MemoryBuffer::getMemBuffer(
+                StringRef((const char *)fbase, (size_t)(((uint64_t)-1)-fbase)),"",false);
+
 #ifdef LLVM35
+            std::unique_ptr<MemoryBuffer> buf(membuf);
             ErrorOr<llvm::object::ObjectFile*> origerrorobj = llvm::object::ObjectFile::createObjectFile(
+                buf, sys::fs::file_magic::unknown);
 #else
             llvm::object::ObjectFile *origerrorobj = llvm::object::ObjectFile::createObjectFile(
+                membuf);
 #endif
-                    MemoryBuffer::getMemBuffer(
-                    StringRef((const char *)fbase, (size_t)(((uint64_t)-1)-fbase)),"",false)
-#ifdef LLVM35
-                    ,false, sys::fs::file_magic::unknown
-#endif
-            );
             if (!origerrorobj) {
                 objfileentry_t entry = {obj,context,slide};
                 objfilemap[fbase] = entry;

I'll commit this on master soon

acroy · 2014-07-24T08:32:44Z

Thanks again! Now Julia seems to build fine, but building CXX.jl fails (see next comment).

In case someone else encounters the same problems, this is what I did to get to this point:

follow Keno's instructions (clone fresh Julia, merge kf/llvmcall and kf/staged, modify src/codegen.cpp:

-static LLVMContext &jl_LLVMContext = getGlobalContext(); 
+DLLEXPORT LLVMContext &jl_LLVMContext = getGlobalContext(); 
 static IRBuilder<> builder(getGlobalContext()); 
 static bool nested_compile=false; 
-static ExecutionEngine *jl_ExecutionEngine; 
+DLLEXPORT ExecutionEngine *jl_ExecutionEngine;

apply the patch given above to src/debuginfo.cpp
create Make.user with the following content

LLVM_VER = svn
LLDB_VER = master

BUILD_LLVM_CLANG=1 
BUILD_LLDB=1
LLVM_ASSERTIONS=1

USECLANG=1
USE_LIBCPP=1

This point is maybe a bit fishy, but I had to change -mmacosx-version-min=10.6 to -mmacosx-version-min=10.7 in Make.inc (I am not sure, but I think the latter needs to be used with libc++ and C++11. For OSX 10.9 the magic in Make.inc seems to take care of this.)
get and configure llvm with make -C deps configure-llvm
to generate DNBConfig.h do

cd deps/llvm-svn/build_Release+Asserts/tools/lldb/tools/debugserver/
make -C scripts

apply this patch to define CPU_SUBTYPE_X86_64_H
build everything with make
depending on your machine get some coffee or a 4 course meal

This got a bit longer than anticipated, but maybe it is helpful for someone.

acroy · 2014-07-24T08:40:25Z

Ok, back to the building error. After removing -lclangRewriteCore I get

Tuning for julia installation at: /Users/acr/Development/Julia/julia-cxx/usr/bin
    CC /Users/acr/Development/Julia/Cxx.jl/deps/build/bootstrap.o
    LINK /Users/acr/Development/Julia/Cxx.jl/deps/usr/lib/libcxxffi.dylib
Undefined symbols for architecture x86_64:
  "_PyArg_Parse", referenced from:
      lldb_private::ScriptInterpreterPython::ExecuteOneLineWithReturn(char const*, lldb_private::ScriptInterpreter::ScriptReturnType, void*, lldb_private::ScriptInterpreter::ExecuteScriptOptions const&) in liblldbInterpreter.a(ScriptInterpreterPython.o)
  "_PyArg_ParseTuple", referenced from:
      __wrap_new_SBAddress in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_delete_SBAddress in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_SBAddress_IsValid in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_SBAddress_Clear in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_SBAddress_GetFileAddress in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_SBAddress_GetLoadAddress in liblldbInterpreter.a(LLDBWrapPython.o)
      __wrap_SBAddress_SetLoadAddress in liblldbInterpreter.a(LLDBWrapPython.o)
      ...
[/snip/]
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [usr/lib/libcxxffi.dylib] Error 1

Maybe there is some mismatch between the build flags used in Make.inc and BuildBootstrap.Makefile?

Keno · 2014-07-24T17:42:10Z

diff --git a/deps/Makefile b/deps/Makefile
index 49f1661..c0b7fb4 100644
--- a/deps/Makefile
+++ b/deps/Makefile
@@ -211,8 +211,8 @@ endif
 endif

 LLVM_TARGET_FLAGS= --enable-targets=host
-LLVM_FLAGS += --disable-profiling --enable-shared --enable-static $(LLVM_TARGET_FLAGS) --disable-bindings --disable-docs
-LLVM_MFLAGS =
+LLVM_FLAGS += --disable-profiling --enable-shared --enable-static $(LLVM_TARGET_FLAGS) --disable-bindings --disable-docs CXXFLAGS="-DLLDB_DISABLE_PYTHON"
+LLVM_MFLAGS = CXXFLAGS="-DLLDB_DISABLE_PYTHON"
 ifeq ($(LLVM_ASSERTIONS), 1)
 LLVM_FLAGS += --enable-assertions
 ifeq ($(OS), WINNT)

LLDB seems to be built with python. Try the above.

Keno · 2014-07-24T18:10:47Z

On master, I also added a LLDB_DISABLE_PYTHON flag which you can put in your Make.user.

acroy · 2014-07-24T22:05:49Z

Unfortunately, the patch doesn't help, but maybe I did it wrong. Rebuilding llvm gives me:

[/snip/]
LLDBWrapPython.cpp:150:10: fatal error: 'Python.h' file not found
#include <Python.h>
         ^
1 error generated.
rm: /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/build_Release+Asserts/tools/lldb/source/Interpreter/Release+Asserts/LLDBWrapPython.d.tmp: No such file or directory
make[7]: *** [/Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/build_Release+Asserts/tools/lldb/source/Interpreter/Release+Asserts/LLDBWrapPython.o] Error 1
make[6]: *** [all] Error 1
make[5]: *** [all] Error 1
make[4]: *** [all] Error 1
make[3]: *** [all] Error 1
make[2]: *** [llvm-svn/build_Release+Asserts/Release+Asserts/lib/libLLVMJIT.a] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

Keno · 2014-07-24T22:08:12Z

That's odd. That file shouldn't really exist with those flags. How did you rebuild llvm? I would recommend throwing away the entire llvm-svn/build_Release+Asserts directory in case you have stale state. Thanks for being the guinea pig and trying this out BTW.

acroy · 2014-07-24T22:29:38Z

No problem. Like everyone else I am quite excited to try this out :-)

Regarding the rebuild: I just did make -C deps clean-llvm; make. Maybe this was not sufficient. I will get rid of the directory you mentioned and start the build again. Might take a while before I can report the result ...

Keno · 2014-07-24T23:32:50Z

The patch to Host.cpp has been committed upstream.

acroy · 2014-07-25T08:45:20Z

Nope, doesn't work. I started from scratch and as you say the patches to Host.cpp and debuginfo.cpp are already included. I set LLDB_DISABLE_PYTHON=1, but get the same error regarding "Python.h".

acroy · 2014-07-28T15:41:01Z

Ok, I got it to build. I suspect that tools/lldb/source/Interpreter/Makefile doesn't respect the flag LLDB_DISABLE_PYTHON (I removed a few lines and now it doesn't complain about python).
Anyways, I had to replace -lclangRewriteCore by -lclangRewrite in your makefile, but now CXX.jl also builds:

julia> Pkg.build("CXX")
INFO: Building CXX
Tuning for julia installation at: /Users/acr/Development/Julia/julia-cxx/usr/bin
    CC /Users/acr/.julia/v0.3/Cxx/deps/build/bootstrap.o
    LINK /Users/acr/.julia/v0.3/Cxx/deps/usr/lib/libcxxffi.dylib
ld: warning: direct access in clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr const*, clang::CodeGen::ReturnValueSlot) to global weak symbol clang::ValueDecl::getType() const means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
Not building debug library because corresponding julia DEBUG library does not exist.
To build, simply run the build again once the the library has been built.

Running a test doesn't work

julia> include("/Users/acr/.julia/v0.3/Cxx/test/llvmtest.jl")
ERROR: error compiling cxxsizeof: ccall: could not find function julia_type_to_llvm
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
while loading /Users/acr/.julia/v0.3/Cxx/test/llvmtest.jl, in expression starting on line 44

Any ideas?

ihnorton · 2014-07-28T15:58:38Z

@acroy see #7 (comment) for a (temporary) solution.

acroy · 2014-07-28T16:20:32Z

@ihnorton : Thanks for the pointer. Where exactly did you add cjulia_type_to_llvm?

jakebolewski · 2014-07-28T16:33:25Z

cgutil.cpp

ihnorton · 2014-07-28T16:35:21Z

Right, just below the def'n of julia_type_to_llvm
On Jul 28, 2014 12:33 PM, "Jake Bolewski" notifications@github.com wrote:

cgutil.cpp
https://github.com/jakebolewski/julia/blob/master/src/cgutils.cpp#L397

—
Reply to this email directly or view it on GitHub
#4 (comment).

acroy · 2014-07-28T17:24:24Z

Sorry for my ignorance, but what then? make clean; make and running the test again doesn't work.

ihnorton · 2014-07-28T17:26:31Z

You need to change the corresponding call in Cxx.jl
On Jul 28, 2014 1:24 PM, "acroy" notifications@github.com wrote:

Sorry for my ignorance, but what then? make clean; make and running the
test again doesn't work.

—
Reply to this email directly or view it on GitHub
#4 (comment).

acroy · 2014-07-28T17:58:04Z

I tried that as well :-) But

julia> ccall(:cjulia_type_to_llvm,Ptr{Void},(Any,),1)
ERROR: ccall: could not find function cjulia_type_to_llvm

Actually, it seems that cgutils.cpp isn't compiled at all ...

Keno · 2014-07-28T18:00:22Z

It's #include'd in codegen.cpp.

On Mon, Jul 28, 2014 at 1:58 PM, acroy notifications@github.com wrote:

I tried that as well :-) But

julia> ccall(:cjulia_type_to_llvm,Ptr{Void},(Any,),1)
ERROR: ccall: could not find function cjulia_type_to_llvm

Actually, it seems that cgutils.cpp isn't compiled at all ...

—
Reply to this email directly or view it on GitHub
#4 (comment).

ihnorton · 2014-07-28T18:07:40Z

Try adding cjulia_* to julia.expmap
On Jul 28, 2014 2:00 PM, "Keno Fischer" notifications@github.com wrote:

It's #include'd in codegen.cpp.

On Mon, Jul 28, 2014 at 1:58 PM, acroy notifications@github.com wrote:

I tried that as well :-) But

julia> ccall(:cjulia_type_to_llvm,Ptr{Void},(Any,),1)
ERROR: ccall: could not find function cjulia_type_to_llvm

Actually, it seems that cgutils.cpp isn't compiled at all ...

—
Reply to this email directly or view it on GitHub
#4 (comment).

—
Reply to this email directly or view it on GitHub
#4 (comment).

acroy · 2014-07-28T20:19:10Z

No, doesn't help. In which lib does it end up?

Keno · 2014-07-28T20:21:06Z

should be in libjulia.

acroy · 2014-07-28T20:43:15Z

Mhmm, it is in libjulia but ccall refuses to find it.

Keno · 2014-07-30T19:59:37Z

Try the following diff:

index d9ed432..8f0a81b 100644
--- a/src/cgutils.cpp
+++ b/src/cgutils.cpp
@@ -394,7 +394,8 @@ static Type *julia_struct_to_llvm(jl_value_t *jt);

 static bool jltupleisbits(jl_value_t *jt, bool allow_unsized = true);

-static Type *julia_type_to_llvm(jl_value_t *jt)
+extern "C" {
+DLLEXPORT Type *julia_type_to_llvm(jl_value_t *jt)
 {
     if (jt == (jl_value_t*)jl_bool_type) return T_int1;
     if (jt == (jl_value_t*)jl_bottom_type) return T_void;
@@ -478,6 +479,7 @@ static Type *julia_type_to_llvm(jl_value_t *jt)
     }
     return jl_pvalue_llvmt;
 }
+}

 static Type *julia_struct_to_llvm(jl_value_t *jt)
 {

(no need for cjulia then, just Cxx.jl as is). This definitely worked for me on OS X.

acroy · 2014-07-30T20:21:36Z

Bingo! Thanks a ton. Now the function is found, but your test kicks me out:

julia> include("/Users/acr/.julia/v0.3/Cxx/test/llvmtest.jl")
Assertion failed: (Val && "isa<> used on a null pointer"), function doit, file /Users/acr/Development/Julia/julia-cxx/deps/llvm-svn/include/llvm/Support/Casting.h, line 95.

signal (6): Abort trap: 6
??? at ???:259608915
??? at ???:259600885
??? at ???:-1761896182
Abort trap: 6

Keno · 2014-07-30T20:25:43Z

Can you run it under lldb and get me a backtrace.

acroy · 2014-07-30T20:59:57Z

I hope I did it right. The backtrace is in this gist.

Keno · 2014-07-30T21:29:10Z

Unfortunately that backtrace doesn't make alll that much sense. You might have to rebuild llvm in debug mode to get a better backtrace (LLVM_DEBUG=1 in Make.user). Before you do that though, try just running the test from the command line.

acroy · 2014-07-30T21:36:49Z

Same error when I run it from the command line. I can try LLVM_DEBUG=1 but it will probably take while before I can look into it. Is there something else I could test?

Keno · 2014-07-30T21:41:35Z

Not that I can think of, sorry. This is usually the point where I give up and build the debug version ;).

acroy · 2014-07-30T21:52:06Z

Well, I always wanted to build llvm in debug mode :-) I will let you know once I got the chance to look into it. Thanks again.

Keno · 2014-08-14T03:10:37Z

The good news is I can now reproduce this failure so, I should have a fix soon.

Keno · 2014-08-15T01:52:40Z

Segfault should be fixed in http://reviews.llvm.org/rL215686. There's one more issue I'll need to work around and I have a build fix pending, so maybe don't try just yet, but soon.

Edit: GitHub link: llvm-mirror/clang@8444ae7

acroy · 2014-08-15T06:44:44Z

Exciting! I am looking forward to try this.

maxruby · 2014-10-29T15:41:48Z

I really would like to try CXX on MacOSX to wrap some C++ libraries and code. I tried to install Cxx.jl on Julia v0.3, OSX 10.9 but I get a fatal error:

This version of julia does not have staged functions.

This is what I did:

Added to ~/.julia/Make.user

LLVM_VER=svn
LLVM_ASSERTIONS=1
#LLVM_DEBUG=1
BUILD_LLVM_CLANG=1
BUILD_LLDB=1
LLDB_VER = master
USE_LLVM_SHLIB=1
LLDB_DISABLE_PYTHON=1

In the REPL I typed,

Pkg.clone("https://github.com/Keno/Cxx.jl")  
Pkg.build("CXX")

I looked for the staged functions, but I am not sure where/how I should install them.
How to proceed? Is CXX working well enough that it is worth trying now?

StefanKarpinski · 2014-10-29T15:43:06Z

You need a development version of Julia – v0.3 doesn't have staged functions.

maxruby · 2014-10-29T15:45:14Z

Thanks! I will try my currently dormant fork of v0.4 . . .

jtravs · 2014-12-06T12:33:11Z

Still can't build this. On julia commit 7dd805feb0e18d08a8159d4b49415af685cf62dc

With my Make.user:

USE_SYSTEM_LIBM=1
LLDB_VER=master
LLVM_VER=svn
LLVM_ASSERTIONS=1
#LLVM_DEBUG=1
BUILD_LLVM_CLANG=1
BUILD_LLDB=1
USE_LLVM_SHLIB=1
LLDB_DISABLE_PYTHON=1

I get this error:

rl: (22) The requested URL returned error: 404 Not Found
make[2]: *** [lldb-svn.src.tar.gz] Error 22

Keno · 2014-12-07T06:59:51Z

@jtravs That error should be fixed by JuliaLang/julia#9263

jtravs · 2014-12-07T15:12:49Z

Thanks! Works perfectly now...

acroy · 2014-12-07T18:04:34Z

Motivated by John's success I decided to try again ... and now it seems to work! Thanks! I had to manually change -mmacosx-version-min=10.6 to -mmacosx-version-min=10.7 and add -stdlib=libc++ in Make.inc (somehow connected to setting USE_LIBCPP=1 but maybe there is something weird in my system).

Running the tests give me warnings and notes about overridden virtual functions for headers in usr/include/lldb/.... Is that Ok? The llvmgraph.jl test failed for me since Graphs was not installed.

Luthaf · 2014-12-10T13:40:16Z

I still can't build on OS X. I get an error about libcompiler_rt.a, which seems to exist in a clang_macho_embedded folder, but not on a clang_darwin/eprintf folder :

ARCHIVE:   clang_macho_embedded/hard_pic/x86_64: /Applications/Julia/deps/llvm-svn/build_Release+Asserts/tools/clang/runtime/compiler-rt/clang_macho_embedded/hard_pic/x86_64/libcompiler_rt.a
  MKDIR:     /Applications/Julia/deps/llvm-svn/build_Release+Asserts/tools/clang/runtime/compiler-rt/clang_macho_embedded/hard_pic
  FINAL-ARCHIVE: clang_macho_embedded/hard_pic: /Applications/Julia/deps/llvm-svn/build_Release+Asserts/tools/clang/runtime/compiler-rt/clang_macho_embedded/hard_pic/libcompiler_rt.a
llvm[7]: Copying runtime library darwin/eprintf to build dir
cp: /Applications/Julia/deps/llvm-svn/build_Release+Asserts/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a: No such file or directory
make[7]: *** [/Applications/Julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/lib/clang/3.6.0/lib/darwin/libclang_rt.eprintf.a] Error 1
make[6]: *** [compiler-rt/.makeall] Error 2
make[5]: *** [all] Error 1
make[4]: *** [clang/.makeall] Error 2
make[3]: *** [all] Error 1
make[2]: *** [llvm-svn/build_Release+Asserts/Release+Asserts/lib/libLLVMCodeGen.a] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

My Make.user :

prefix=/usr/local

OPENBLAS DYNAMIC ARCH=1

LLDB_VER=master
LLVM_VER=svn
LLVM_ASSERTIONS=1
BUILD_LLVM_CLANG=1

BUILD_LLDB=1
USE_LLVM_SHLIB=1
LLDB_DISABLE_PYTHON=1

Luthaf · 2014-12-12T13:01:48Z

Ok, this was fixed by installing the full XCode.app, instead of using only the command line tools.

It's maybe worth adding a line about this in the README.

Keno mentioned this issue Dec 7, 2014

Fix git lldb build JuliaLang/julia#9263

Merged

jtravs mentioned this issue Dec 7, 2014

missing CodeGenModule.h #18

Closed

jtravs closed this as completed Dec 7, 2014

ts826848 mentioned this issue Jul 28, 2015

llvm --with-clang --with-lldb fails to build Homebrew/legacy-homebrew#42041

Closed

tbreloff mentioned this issue Sep 30, 2015

Errors building Julia v0.5 on OSX #162

Closed

Can't build on OSX #4

Can't build on OSX #4

Comments

jtravs commented Jul 23, 2014

ihnorton commented Jul 23, 2014

acroy commented Jul 23, 2014

jtravs commented Jul 23, 2014

ihnorton commented Jul 23, 2014

acroy commented Jul 23, 2014

ihnorton commented Jul 23, 2014

ihnorton commented Jul 23, 2014

Keno commented Jul 23, 2014

acroy commented Jul 23, 2014

Keno commented Jul 23, 2014

acroy commented Jul 23, 2014

Keno commented Jul 23, 2014

acroy commented Jul 24, 2014

acroy commented Jul 24, 2014

Keno commented Jul 24, 2014

Keno commented Jul 24, 2014

acroy commented Jul 24, 2014

Keno commented Jul 24, 2014

acroy commented Jul 24, 2014

Keno commented Jul 24, 2014

acroy commented Jul 25, 2014

acroy commented Jul 28, 2014

ihnorton commented Jul 28, 2014

acroy commented Jul 28, 2014

jakebolewski commented Jul 28, 2014

ihnorton commented Jul 28, 2014

acroy commented Jul 28, 2014

ihnorton commented Jul 28, 2014

acroy commented Jul 28, 2014

Keno commented Jul 28, 2014

ihnorton commented Jul 28, 2014

acroy commented Jul 28, 2014

Keno commented Jul 28, 2014

acroy commented Jul 28, 2014

Keno commented Jul 30, 2014

acroy commented Jul 30, 2014

Keno commented Jul 30, 2014

acroy commented Jul 30, 2014

Keno commented Jul 30, 2014

acroy commented Jul 30, 2014

Keno commented Jul 30, 2014

acroy commented Jul 30, 2014

Keno commented Aug 14, 2014

Keno commented Aug 15, 2014

acroy commented Aug 15, 2014

maxruby commented Oct 29, 2014

StefanKarpinski commented Oct 29, 2014

maxruby commented Oct 29, 2014

jtravs commented Dec 6, 2014

Keno commented Dec 7, 2014

jtravs commented Dec 7, 2014

acroy commented Dec 7, 2014

Luthaf commented Dec 10, 2014

Luthaf commented Dec 12, 2014