Build issues on linux

[few]

I compiled julia using this Make.user:
LLVM_ASSERTIONS=1
LLVM_VER=svn
BUILD_LLVM_CLANG=1
BUILD_LLDB=1
LLDB_VER=master
USE_LLVM_SHLIB=1
LLDB_DISABLE_PYTHON=1
(this could be added to README.md btw)

and then:

julia> Pkg.clone("https://github.com/Keno/Cxx.jl.git")
INFO: Cloning Cxx from https://github.com/Keno/Cxx.jl.git
INFO: Computing changes...
julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: /home/luther/software/julia_cxx/usr/bin
CC /home/luther/.julia/v0.4/Cxx/deps/build/bootstrap.o
LINK /home/luther/.julia/v0.4/Cxx/deps/usr/lib/libcxxffi.so
/usr/bin/ld: cannot find -llldbCore
/usr/bin/ld: cannot find -llldbDataFormatters
/usr/bin/ld: cannot find -llldbExpression
(and lots of other lldb libs)

These libs are indeed missing:
$ ls usr/lib/liblldb*
usr/lib/liblldbAPI.a usr/lib/liblldbBreakpoint.a usr/lib/liblldbCommands.a usr/lib/liblldbInitAndLog.a

[few]

I found that this is a problem on my side. I had missing dependencies for lldb, but the build didn't fail. Now struggling with another failure:
llvm[2]: Linking Release+Asserts Shared Library liblldb.so
In function lldb_private::NativeProcessLinux::OperationArgs::OperationArgs(lldb_private::NativeProcessLinux*)': NativeProcessLinux.cpp:(.text._ZN12lldb_private18NativeProcessLinux13OperationArgsC2EPS0_+0x1a): undefined reference tosem_init'

Edit:
The other problem is described here:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-September/005194.html

I hacked around it by adding
LLVMLibsOptions += -lpthread
at the end of deps/llvm-svn/build_Release+Asserts/tools/lldb/lib/Makefile

[few]

Problem is not solved. Building lldb seemed to succeed, but using Cxx didn't work later on. The reason is that libcxxffi.so has undefined symbols from llvm. From the names of these symbols I guessed that they are related to threading. I guess lldb somehow requires llvm to be build with threads enabled, but julia disables them in (deps/Makefile). I'm now trying to build llvm with threads enabled.

[few]

It works now. There seem to be four problems.
1) llvm needs to be build without --disable-threads (required by lldb)
2) There are some new lldb libs missing from LLDB_LIBS in BuildBootstrap.Makefile
3) lldb requires ncurses
4) On ubuntu14.04 --as-needed is on by default, making the order of libs on the command line important.

Edit: Enabling threads is not necessary, but then you need to pass -lpthread while linking liblldb.so and libcxxffi.so.

Here is what I did:

diff --git a/deps/BuildBootstrap.Makefile b/deps/BuildBootstrap.Makefile
index 3a3eaf3..fd443fc 100644
--- a/deps/BuildBootstrap.Makefile
+++ b/deps/BuildBootstrap.Makefile
@@ -32,6 +32,7 @@ LLDB_LIBS = -llldbAPI -llldbBreakpoint -llldbCommands -llldbCore \
     -llldbPluginInstrumentationRuntimeAddressSanitizer \
     $(call exec,$(LLVM_CONFIG) --system-libs)
 LLDB_LIBS += -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_arm64 -llldbPluginABIMacOSX_i386
+LLDB_LIBS += -llldbPluginDynamicLoaderHexagon -llldbPluginABISysV_hexagon -llldbPluginDynamicLoaderMacOSX
 ifeq ($(OS), Darwin)
 LLDB_LIBS += -F/System/Library/Frameworks -F/System/Library/PrivateFrameworks -framework DebugSymbols -llldbHostMacOSX \
        -llldbHostPOSIX \
@@ -45,14 +46,17 @@ ifeq ($(OS), WINNT)
 LLDB_LIBS += -llldbHostWindows -llldbPluginProcessWindows -lWs2_32
 endif
 ifeq ($(OS), Linux)
-LLDB_LIBS += -llldbHostLinux -llldbPluginProcessLinux -llldbPluginProcessPOSIX
+LLDB_LIBS += -llldbHostLinux -llldbHostPosix -llldbPluginProcessLinux -llldbPluginProcessPOSIX -lncurses -lpanel -lrt -lpthread
 endif


 ifeq ($(USE_LLVM_SHLIB),1)
-LDFLAGS += -lLLVM-$(call exec,$(LLVM_CONFIG) --version)
+LLVM_LIBS = -lLLVM-$(call exec,$(LLVM_CONFIG) --version)
+else
+LLVM_LIBS =
 endif

+LDFLAGS += -Wl,--no-undefined

 all: usr/lib/libcxxffi.$(SHLIB_EXT) usr/lib/libcxxffi-debug.$(SHLIB_EXT)

@@ -68,7 +72,7 @@ build/bootstrap.o: ../src/bootstrap.cpp BuildBootstrap.Makefile | build

 ifneq (,$(wildcard $(build_shlibdir)/libjulia.$(SHLIB_EXT)))
 usr/lib/libcxxffi.$(SHLIB_EXT): build/bootstrap.o | usr/lib
-       @$(call PRINT_LINK, $(CXX) -shared -fPIC $(JULIA_LDFLAGS) -ljulia $(LDFLAGS) -o $@ $(WHOLE_ARCHIVE) $(CLANG_LIBS) $(LLDB_LIBS) $(NO_WHOLE_ARCHIVE) $< )
+       @$(call PRINT_LINK, $(CXX) -shared -fPIC $(JULIA_LDFLAGS)  $(LDFLAGS) -o $@ $(WHOLE_ARCHIVE) $(CLANG_LIBS) $(LLDB_LIBS) $(LLVM_LIBS) $(NO_WHOLE_ARCHIVE) $< -ljulia )
        @cp usr/lib/libcxxffi.$(SHLIB_EXT) $(build_shlibdir)
 else
 usr/lib/libcxxffi.$(SHLIB_EXT):

[timholy]

@few, I ran into what I suspect is the same error:

julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: /home/tim/src/julia/usr/bin
    LINK /usr/local/julia/julia-packages/v0.4/Cxx/deps/usr/lib/libcxxffi.so
/home/tim/src/julia/usr/bin/../../usr/lib/liblldbPluginProcessGDBRemote.a(GDBRemoteCommunication.o): In function `GDBRemoteCommunication::StartDebugserverProcess(char const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)':
GDBRemoteCommunication.cpp:(.text._ZN22GDBRemoteCommunication23StartDebugserverProcessEPKctRN12lldb_private17ProcessLaunchInfoERt+0x620): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'

julia> using Cxx
ERROR: error compiling init: could not load module libcxxffi: libcxxffi: cannot open shared object file: No such file or directory
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in require4127 at /home/tim/src/julia/usr/bin/../lib/julia/sys.so
 in print at ./string.jl
while loading /usr/local/julia/julia-packages/v0.4/Cxx/src/Cxx.jl, in expression starting on line 37

I made the changes described in your post above, but got this:

julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: /home/tim/src/julia/usr/bin
    CC /usr/local/julia/julia-packages/v0.4/Cxx/deps/build/bootstrap.o
    LINK /usr/local/julia/julia-packages/v0.4/Cxx/deps/usr/lib/libcxxffi.so
/home/tim/src/julia/usr/bin/../../usr/lib/liblldbPluginProcessGDBRemote.a(GDBRemoteCommunication.o): In function `GDBRemoteCommunication::StartDebugserverProcess(char const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)':
GDBRemoteCommunication.cpp:(.text._ZN22GDBRemoteCommunication23StartDebugserverProcessEPKctRN12lldb_private17ProcessLaunchInfoERt+0x620): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/home/tim/src/julia/usr/bin/../../usr/lib/liblldbHostCommon.a(Editline.o): In function `std::_Sp_counted_ptr<lldb_private::line_editor::EditlineHistory*, (__gnu_cxx::_Lock_policy)2>::_M_dispose()':
Editline.cpp:(.text._ZNSt15_Sp_counted_ptrIPN12lldb_private11line_editor15EditlineHistoryELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv[_ZNSt15_Sp_counted_ptrIPN12lldb_private11line_editor15EditlineHistoryELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv]+0x34): undefined reference to `history'
Editline.cpp:(.text._ZNSt15_Sp_counted_ptrIPN12lldb_private11line_editor15EditlineHistoryELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv[_ZNSt15_Sp_counted_ptrIPN12lldb_private11line_editor15EditlineHistoryELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv]+0x41): undefined reference to `history_end'
/home/tim/src/julia/usr/bin/../../usr/lib/liblldbHostCommon.a(Editline.o): In function `lldb_private::Editline::IsEmacs()':
Editline.cpp:(.text._ZN12lldb_private8Editline7IsEmacsEv+0x14): undefined reference to `el_get'
...

I'm a build noob. Any insights?

[few]

@timholy: As Keno said in some other issue, you don't need lldb. I'd say the easiest way forward for you would be to remove $(LLVM_LIBS) from the $(CXX) invocations in BuildBootstrap.Makefile.

[Keno]

Seems like everything in this issue is resolved? If so, I'm gonna close this. Please open new issues for any specific new failures.

[few]

I didn't try the lldb part, but otherwise it works for me. Would you consider dropping the lldb dependency to speedup and simplify the installation for users?

[Keno]

Yes, that's not an unreasonable request. I'm planning to do something more standalone with lldb in the very near future, so I'll look into build options that allow lldb to use clang as built into this library, but without having to have them be in the same shared library.