search

clasp-developers / clasp

clasp Common Lisp environment
https://clasp-developers.github.io/
2.58k stars 145 forks source link

build fails at linking cclasp-boehm; with non-standard libboost location #299

Closed attila-lendvai closed 8 years ago

attila-lendvai commented 8 years ago

i'm on Debian stable and therefore had to build a fresh libboost myself. i installed it under /opt.

this is how i need to build clasp, which works almost until the end, but fails when linking cclasp_boehm:

CXXFLAGS="-I/opt/boost_1_62_0/include" LDFLAGS="-L/opt/boost_1_62_0/lib" EXTERNALS_CLASP_DIR=/media/store/work/clasp/externals-clasp/ PJOBS=2 make

i can successfully finish building cclasp if i hardcode this into the wscript file, into the link_executable task:

-L/opt/boost_1_62_0/lib -Wl,-rpath=/opt/boost_1_62_0/lib

cclasp then can successfully compile-file and load fasls.

the resulting cclasp has no clue about the libboost path, though:

$ ./cclasp-boehm
Starting Boehm cclasp 0.4.0-1039-g2eb181f ... loading image... it takes a few seconds
Top level.
> core:*build-linkflags*

"-L/media/store/work/clasp/externals-clasp/build/release/lib -fuse-ld=gold -stdlib=libstdc++ -lstdc++ -pthread -flto=thin -fvisibility=default -rdynamic"
> core:*build-stlib*

" -lclangASTMatchers -lclangDynamicASTMatchers -lclangIndex -lclangTooling -lclangFormat -lclangToolingCore -lclangBasic -lclangCodeGen -lclangDriver -lclangFrontend -lclangFrontendTool -lclangCodeGen -lclangRewriteFrontend -lclangARCMigrate -lclangStaticAnalyzerFrontend -lclangFrontend -lclangDriver -lclangParse -lclangSerialization -lclangSema -lclangEdit -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangAnalysis -lclangAST -lclangRewrite -lclangLex -lclangBasic -lLLVMLTO -lLLVMObjCARCOpts -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMObjectYAML -lLLVMGlobalISel -lLLVMLibDriver -lLLVMOption -lLLVMCoverage -lLLVMTableGen -lLLVMOrcJIT -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMLineEditor -lLLVMPasses -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMMIRParser -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMMC -lLLVMBitWriter -lLLVMBitReader -lLLVMAnalysis -lLLVMProfileData -lLLVMAsmParser -lLLVMCore -lLLVMSupport -lboost_filesystem -lboost_regex -lboost_date_time -lboost_program_options -lboost_system -lboost_iostreams -lz -lgc"
> core:*build-lib*

" -ldl -lncurses -lm -lgmpxx -lgmp"
>
drmeister commented 8 years ago

attila-lendvai: Could you try taking out the change to link_executable and try this: CXXFLAGS="-I/opt/boost_1_62_0/include" LINKFLAGS="-L/opt/boost_1_62_0/lib -Wl,-rpath=/opt/boost_1_62_0/lib" EXTERNALS_CLASP_DIR=/media/store/work/clasp/externals-clasp/ PJOBS=2 make

I suggest this because LINKFLAGS from the shell environment should be read by the waf build system and the fact that I explicitly write the value of LINKFLAGS into the C++ source code of iclasp/cclasp.

My thinking is based on the belief that the environment variables that waf listens to are listed here: https://waf.io/book/#_library_interaction_use

drmeister commented 8 years ago

waf does read LINKFLAGS from the shell environment along with LDFLAGS. It says that LINKFLAGS is the 'list of link flags' and LDFLAGS is the 'list of link flags at the end of the link command'. Since they are both used I should string the two of them together and put that into core:build-linkflags. How does that sound?

drmeister commented 8 years ago

This should be fixed in 1077f2d

attila-lendvai commented 8 years ago

fixed in testing, closing.