Closed drmeister closed 9 years ago
There are several other libraries and programs listed in the README. What about installations for those?
Here is a progress report on this. I'm testing in a jessie chroot (created using debootstrap).
1) First, install some build dependencies
apt-get install gcc g++ libboost-dev clang-3.6 llvm-3.6-dev libgc-dev libgmp-dev
libclang-3.6-dev libreadline-dev zlib1g-dev libexpat1-dev
libboost-iostreams1.55-dev libboost-system1.55-dev
libboost-program-options1.55-dev libboost-date-time1.55-dev
libboost-regex1.55-dev libboost-filesystem1.55-dev libffi-dev
My local.config is
##################################################
# Pastebin L6WoHt9R
#
# What system are you building on? linux or darwin
#
export TARGET_OS = linux
#
# This defines where clasp should put the built clasp application
#
export CLASP_BUILD_TARGET_DIR = $(HOME)/local/clasp
#
# This defines where externals-clasp put the built libraries
# that clasp needs
#
#export EXTERNALS_BUILD_TARGET_DIR = $(HOME)/local/externals-clasp
export EXTERNALS_BUILD_TARGET_DIR = /usr
#
# This defines how many processors you have available to build with
# More processors = faster build
#
export PJOBS = 1
# --- Dont change the stuff below ---
export LINK = static
export ADDRESS-MODEL = 64
export CLASP_CLANG_PATH = /usr/bin/clang-3.6
#########################################
I needed to apply the following patch
diff --git a/Jamroot.jam b/Jamroot.jam
index b1620a5..5ea7041 100644
--- a/Jamroot.jam
+++ b/Jamroot.jam
@@ -34,6 +34,12 @@ project clasp : requirements
<target-os>darwin:<linkflags>"-lc++"
<define>INCLUDED_FROM_CLASP
<include>$(APPRES-EXTERNALS-RELEASE-INCLUDE)
+ <include>"/usr/include/llvm-3.6/"
+ <include>"/usr/include/llvm-c-3.6/"
+ <include>"/usr/lib/llvm-3.6/include/"
+ <linkflags>"-lstdc++"
+ <linkflags>"-lm"
+ <linkflags>"-lffi"
<define>EXPAT
<cxxflags>"-Wgnu-array-member-paren-init"
The build currently exits with the following error. I tracked this down to a difference in the file reclaim.c
in the Boehm library. The Boehm 7.2 in externals clasp differs in small but important respects from the one on Debian, specifically the reclaim.c
file, which is where GC_mercury_enumerate_reachable_objects
is defined in the externals versioni.
In the Debian one it is missing. Looks like nobody has actually tried to compile this against a regular Boehm library before this. So, the question is, where did this Boehm (in exernals) come from?
The reclaim.c in the GitHub repos doesn't have this function, so my guess is that it is a local patch.
##########################################################################
...updating 1 target...
clang-linux.link /home/faheem/local/clasp/bin/clasp_boehm_o
../../src/gctools/bundle/libgctools_boehm_opt.a(gctoolsPackage.o): In function `gctools::af_room(gctools::smart_ptr<core::T_O>, gctools::smart_ptr<core::Fixnum_O>, gctools::smart_ptr<core::Str_O>)':
/usr/local/src/clasp/src/main/../../src/gctools/gctoolsPackage.cc:460: undefined reference to `GC_mercury_enumerate_reachable_objects'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
"/usr/bin/clang-3.6" -L"/usr/common/lib" -L"/usr/release/lib" -Wl,-rpath-link -Wl,"/usr/common/lib" -Wl,-rpath-link -Wl,"/usr/release/lib" -o "/home/faheem/local/clasp/bin/clasp_boehm_o" "bin/boehm/clang-linux-3.6.0/release/link-static/main.o" "bin/boehm/clang-linux-3.6.0/release/link-static/mymps.o" "bin/boehm/clang-linux-3.6.0/release/link-static/gc_interface.o" "../../src/core/bundle/libcore_boehm_opt.a" "../../src/asttooling/bundle/libasttooling_boehm_opt.a" "../../src/serveEvent/bundle/libserveEvent_boehm_opt.a" "../../src/sockets/bundle/libsockets_boehm_opt.a" "../../src/gctools/bundle/libgctools_boehm_opt.a" "../../src/clbind/bundle/libclbind_boehm_opt.a" "../../src/llvmo/bundle/libllvmo_boehm_opt.a" "../../src/cffi/bundle/libcffi_boehm_opt.a" "../../src/core/bundle/libcore_boehm_opt.a" -lclangASTMatchers -lclangDynamicASTMatchers -lclangTooling -lclangFrontendTool -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangStaticAnalyzerFrontend -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangARCMigrate -lclangRewriteFrontend -lclangRewrite -lclangAnalysis -lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMMCJIT -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMProfileData -lLLVMOption -lLLVMObjCARCOpts -lLLVMLinker -lLLVMIRReader -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation -lLLVMBitWriter -lLLVMAsmParser -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMBitReader -lLLVMCore -lLLVMX86Utils -lLLVMSupport -lgmpxx -lgmp -lncurses -lreadline -lz -lexpat -lboost_iostreams -lboost_system -lboost_program_options -lboost_date_time -lboost_regex -lboost_filesystem -lrt -lgc -lgmpxx -lgmp -lncurses -lreadline -lz -lexpat -lboost_iostreams -lboost_system -lboost_program_options -lboost_date_time -lboost_regex -lboost_filesystem -lclangASTMatchers -lclangDynamicASTMatchers -lclangTooling -lclangFrontendTool -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangStaticAnalyzerFrontend -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangARCMigrate -lclangRewriteFrontend -lclangRewrite -lclangAnalysis -lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMMCJIT -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMProfileData -lLLVMOption -lLLVMObjCARCOpts -lLLVMLinker -lLLVMIRReader -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation -lLLVMBitWriter -lLLVMAsmParser -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMBitReader -lLLVMCore -lLLVMX86Utils -lLLVMSupport -fvisibility=default -lffi -lm -lpthread -ldl -lstdc++ -rdynamic
...failed clang-linux.link /home/faheem/local/clasp/bin/clasp_boehm_o...
...failed updating 1 target...
makefile:73: recipe for target 'clasp-boehm' failed
It's all coming back to me now. I hacked/enhanced the Boehm library to allow Clasp to take an inventory of all objects in memory and Clasp depends on the enhanced version of the Boehm Library in externals-clasp. I have to move the Boehm library from externals-clasp into clasp/ because of this. Then both garbage collector libraries will be embedded within Clasp.
Including the Boehm Library would not be a good long term solution, and would create problems with distributions. Debian, at least. Here are a couple of alternative suggestions.
1) Ask upstream - possibly https://github.com/ivmai/bdwgc/ to take your code enhancement. Possible problems with this: a) upstream won't want it. b) since apparently you didn't write it, and if you can't track down who did, are you in a position to offer the code? :-)
2) Include the code in Clasp and link against the Boehm library. As you point out, this may not work if the change needs to be compiled into Boehm.
It looks like Peter Wang from the Mercury project posted that code, looking at http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/5904 Third message in the thread. Hence, the mercury in that function...
Related issue - https://github.com/ivmai/bdwgc/issues/56
Needs to be reevaluated as per #135
I had to install libraries for ncurses-dev and libbz2-dev.
sudo apt-get install ncurses-dev sudo apt-get install libbz2-dev