Calypso won't link after ldc-0.16.1 update

[wilsonk]

Hey Elie,

I just did a pull (which went fine) and a submodule update and then tried to remake Calypso by removing the entire bulid dir and running cmake. It all compiles but it just won't link. I get dozens of undefined references when trying to link ldc2? Some examples:

deps/clang/lib/libclangLex.a(Lexer.cpp.o): In function `llvm::sys::UnicodeCharSet::rangesAreValid() const':
Lexer.cpp:(.text._ZNK4llvm3sys14UnicodeCharSet14rangesAreValidEv[_ZNK4llvm3sys14UnicodeCharSet14rangesAreValidEv]+0x6d): undefined reference to `llvm::DebugFlag'

deps/clang/lib/libclangCodeGen.a(CoverageMappingGen.cpp.o): In function `(anonymous namespace)::CounterCoverageMappingBuilder::subtractCounters(llvm::coverage::Counter, llvm::coverage::Counter)':
CoverageMappingGen.cpp:(.text._ZN12_GLOBAL__N_129CounterCoverageMappingBuilder16subtractCountersEN4llvm8coverage7CounterES3_+0x2e): undefined reference to `llvm::coverage::CounterExpressionBuilder::subtract(llvm::coverage::Counter, llvm::coverage::Counter)'
deps/clang/lib/libclangCodeGen.a(CoverageMappingGen.cpp.o): In function `(anonymous namespace)::CounterCoverageMappingBuilder::addCounters(llvm::coverage::Counter, llvm::coverage::Counter)':
CoverageMappingGen.cpp:(.text._ZN12_GLOBAL__N_129CounterCoverageMappingBuilder11addCountersEN4llvm8coverage7CounterES3_+0x2e): undefined reference to `llvm::coverage::CounterExpressionBuilder::add(llvm::coverage::Counter, llvm::coverage::Counter)'
deps/clang/lib/libclangCodeGen.a(CoverageMappingGen.cpp.o): In function `(anonymous namespace)::CounterCoverageMappingBuilder::write(llvm::raw_ostream&)':
CoverageMappingGen.cpp:(.text._ZN12_GLOBAL__N_129CounterCoverageMappingBuilder5writeERN4llvm11raw_ostreamE+0x116): undefined reference to `llvm::coverage::CoverageMappingWriter::write(llvm::raw_ostream&)'

Missing libs? I wonder how your version built? I am still on llvm-3.6.2 if that matters?

[Syniurge]

Hi Kelly,

The first error means that it's linking Calypso built in Debug mode against Release LLVM. It's weird that it got past the cmake call which should have detected this..

Currently building Calypso in release mode against my system's LLVM 3.6 to see if it happens to me as well.

[Syniurge]

It works for me, and if I try to build Calypso in Debug mode while LLVM is in Release mode cmake tells me that it's not possible.

Could you go in build/deps/clang and check if cmake is using the correct LLVM setup with cmake -L?

Mine are:

-- Cache values
BUILD_CLANG_FORMAT_VS_PLUGIN:BOOL=OFF
CLANG_BUILD_EXAMPLES:BOOL=OFF
CLANG_ENABLE_ARCMT:BOOL=ON
CLANG_ENABLE_STATIC_ANALYZER:BOOL=ON
CLANG_INCLUDE_DOCS:BOOL=OFF
CLANG_INCLUDE_TESTS:BOOL=OFF
CLANG_ORDER_FILE:FILEPATH=
CLANG_PLUGIN_SUPPORT:BOOL=ON
CLANG_REPOSITORY_STRING:STRING=
CLANG_RESOURCE_DIR:STRING=
CLANG_TABLEGEN:STRING=clang-tblgen
CLANG_VENDOR:STRING=
CLANG_VENDOR_UTI:STRING=org.llvm.clang
CMAKE_BUILD_TYPE:STRING=RelWithDebInfo
CMAKE_INSTALL_PREFIX:PATH=/usr/local
C_INCLUDE_DIRS:STRING=
DEFAULT_SYSROOT:PATH=
GCC_INSTALL_PREFIX:PATH=
LIBCLANG_BUILD_STATIC:BOOL=OFF
LLVM_BINARY_DIR:PATH=/usr/lib/llvm-3.6
LLVM_CONFIG:FILEPATH=/usr/bin/llvm-config-3.6
LLVM_ENABLE_EH:BOOL=OFF
LLVM_ENABLE_RTTI:BOOL=OFF
LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR:PATH=/home/syniurge/Projets/Calypso/deps/clang/tools/extra
LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN:BOOL=OFF
LLVM_INSTALL_TOOLCHAIN_ONLY:BOOL=OFF
LLVM_LIBRARY_DIR:PATH=/usr/lib/llvm-3.6/lib
LLVM_LIT:FILEPATH=LLVM_LIT-NOTFOUND
LLVM_MAIN_INCLUDE_DIR:PATH=/usr/lib/llvm-3.6/include
LLVM_MAIN_SRC_DIR:PATH=/usr/lib/llvm-3.6/build
LLVM_TABLEGEN_EXE:FILEPATH=/usr/lib/llvm-3.6/bin/llvm-tblgen
LLVM_TOOLS_BINARY_DIR:PATH=/usr/lib/llvm-3.6/bin
TOOL_INFO_PLIST:STRING=Info.plist

[wilsonk]

I have tried to build 'six ways to Sunday' and I just can't get things working here in Debug, Release or RelWithDebInfo mode! Same problems with undefined refs. Here is my 'cmake -L' info:

BUILD_CLANG_FORMAT_VS_PLUGIN:BOOL=OFF
CLANG_BUILD_EXAMPLES:BOOL=OFF
CLANG_ENABLE_ARCMT:BOOL=ON
CLANG_ENABLE_STATIC_ANALYZER:BOOL=ON
CLANG_INCLUDE_DOCS:BOOL=OFF
CLANG_INCLUDE_TESTS:BOOL=ON
CLANG_ORDER_FILE:FILEPATH=
CLANG_PLUGIN_SUPPORT:BOOL=ON
CLANG_REPOSITORY_STRING:STRING=
CLANG_RESOURCE_DIR:STRING=
CLANG_TABLEGEN:STRING=clang-tblgen
CLANG_TEST_USE_VG:BOOL=OFF
CLANG_VENDOR:STRING=
CLANG_VENDOR_UTI:STRING=org.llvm.clang
CMAKE_BUILD_TYPE:STRING=
CMAKE_INSTALL_PREFIX:PATH=/usr/local
C_INCLUDE_DIRS:STRING=
DEFAULT_SYSROOT:PATH=
GCC_INSTALL_PREFIX:PATH=
LIBCLANG_BUILD_STATIC:BOOL=OFF
LLVM_BINARY_DIR:PATH=/usr/local
LLVM_CONFIG:FILEPATH=/usr/local/bin/llvm-config
LLVM_ENABLE_EH:BOOL=OFF
LLVM_ENABLE_RTTI:BOOL=OFF
LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR:PATH=/home/wilsonk/Downloads/Calypso/deps/clang/tools/extra
LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN:BOOL=OFF
LLVM_INSTALL_TOOLCHAIN_ONLY:BOOL=OFF
LLVM_LIBRARY_DIR:PATH=/usr/local/lib
LLVM_LIT_ARGS:STRING=-sv
LLVM_MAIN_INCLUDE_DIR:PATH=/usr/local/include
LLVM_MAIN_SRC_DIR:PATH=/home/wilsonk/Downloads/llvm/llvm
LLVM_TABLEGEN_EXE:FILEPATH=/usr/local/bin/llvm-tblgen
LLVM_TOOLS_BINARY_DIR:PATH=/usr/local/bin
TOOL_INFO_PLIST:STRING=Info.plist

[Syniurge]

That's very weird. Could you check the failing ld call arguments with make VERBOSE=1?

[wilsonk]

/usr/bin/cmake -E cmake_link_script CMakeFiles/ldc2.dir/link.txt --verbose=1
/usr/local/bin/clang++    -std=c++11    CMakeFiles/ldc2.dir/driver/cl_options.cpp.o CMakeFiles/ldc2.dir/driver/codegenerator.cpp.o CMakeFiles/ldc2.dir/driver/configfile.cpp.o CMakeFiles/ldc2.dir/driver/exe_path.cpp.o CMakeFiles/ldc2.dir/driver/targetmachine.cpp.o CMakeFiles/ldc2.dir/driver/toobj.cpp.o CMakeFiles/ldc2.dir/driver/tool.cpp.o CMakeFiles/ldc2.dir/driver/linker.cpp.o CMakeFiles/ldc2.dir/driver/main.cpp.o CMakeFiles/ldc2.dir/driver/ldc-version.cpp.o  -o bin/ldc2 -rdynamic lib/libldc.a -lconfig -lpthread -ldl -ltinfo deps/clang/lib/libclangFrontend.a deps/clang/lib/libclangDriver.a deps/clang/lib/libclangCodeGen.a deps/clang/lib/libclangSerialization.a deps/clang/lib/libclangSema.a deps/clang/lib/libclangEdit.a deps/clang/lib/libclangAnalysis.a deps/clang/lib/libclangAST.a deps/clang/lib/libclangParse.a deps/clang/lib/libclangSema.a deps/clang/lib/libclangEdit.a deps/clang/lib/libclangAnalysis.a deps/clang/lib/libclangAST.a deps/clang/lib/libclangParse.a deps/clang/lib/libclangLex.a deps/clang/lib/libclangBasic.a -lLLVMOption -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMInstrumentation -lLLVMBitWriter -lLLVMAsmParser -lLLVMR600CodeGen -lLLVMipo -lLLVMVectorize -lLLVMR600AsmParser -lLLVMR600Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMProfileData -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMX86Desc -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMMC -lLLVMX86Utils -lLLVMCore -lLLVMSupport -L/usr/local/lib -lz -lpthread -ltinfo -ldl -lm -lpthread -ldl -ltinfo

[Syniurge]

The llvm::coverage symbols should be in libLLVMProfileData (regardless of CMAKE_BUILD_TYPE) which is being linked so I don't get it..

[Syniurge]

Kelly could you check /usr/local/bin/llvm-config --version? llvm::coverage::CounterExpressionBuilder appeared in LLVM 3.6, it wasn't in 3.5.

[wilsonk]

Hey Elie,

Yeah, I checked llvm-config --version long ago and it is version 3.6.2. I tried linking with g++ and I still get the same dozens (or hundreds really) of undefined references. I don't get it.

[Syniurge]

ld --verbose tells where it's getting the libs, and clang++ --verbose provides the ld call arguments.

Could you check if ld is selecting the right LLVM libs on your system?

[wilsonk]

Everything looks fine with the ld call. llvm-config --version is 3.6.2 and it is in /usr/local/bin. The LLVM libs are in /usr/local/lib and they are all 'succeeding', the libclang libs are being 'successfully' picked?!?!? I don't get it and I am getting extremely frustrated, unfortunately.

. . .

(deps/clang/lib/libclangBasic.a)Warnings.cpp.o
attempt to open /usr/local/lib/libLLVMOption.so succeeded
-lLLVMOption (/usr/local/lib/libLLVMOption.so)
attempt to open /usr/local/lib/libLLVMLTO.so succeeded
-lLLVMLTO (/usr/local/lib/libLLVMLTO.so)
attempt to open /usr/local/lib/libLLVMObjCARCOpts.so succeeded
-lLLVMObjCARCOpts (/usr/local/lib/libLLVMObjCARCOpts.so)
attempt to open /usr/local/lib/libLLVMLinker.so succeeded
-lLLVMLinker (/usr/local/lib/libLLVMLinker.so)
attempt to open /usr/local/lib/libLLVMInstrumentation.so succeeded
-lLLVMInstrumentation (/usr/local/lib/libLLVMInstrumentation.so)
attempt to open /usr/local/lib/libLLVMBitWriter.so succeeded
-lLLVMBitWriter (/usr/local/lib/libLLVMBitWriter.so)
attempt to open /usr/local/lib/libLLVMAsmParser.so succeeded
-lLLVMAsmParser (/usr/local/lib/libLLVMAsmParser.so)
attempt to open /usr/local/lib/libLLVMR600CodeGen.so succeeded
-lLLVMR600CodeGen (/usr/local/lib/libLLVMR600CodeGen.so)
attempt to open /usr/local/lib/libLLVMipo.so succeeded
-lLLVMipo (/usr/local/lib/libLLVMipo.so)

. . .

The only failures I see are when looking for libpthread in some directories before it finally finds the right dir...this makes no sense!!!!

[wilsonk]

Looks like this has been fixed now Elie. I just built a new Calypso today and things built fine since the ldc-0.17.1 update.

[Syniurge]

Hi Kelly, glad to hear it's gone and to see you back!