Build error fails at MachineInstr const* for the past two days

Project Infrastructure LLVM Dev List Archives
#1

I keep getting this error upon building:

Linking CXX executable …/…/bin/opt
…/…/lib/libLLVMTarget.so: error: undefined reference to ‘llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData const*, llvm::MachineInstr const*) const’
…/…/lib/libLLVMTarget.so: error: undefined reference to ‘llvm::TargetInstrInfo::getInstrLatency(llvm::InstrItineraryData const*, llvm::MachineInstr const*, unsigned int*) const’
…/…/lib/libLLVMTarget.so: error: undefined reference to ‘llvm::TargetInstrInfo::hasLowDefLatency(llvm::InstrItineraryData const*, llvm::MachineInstr const*, unsigned int) const’
…/…/lib/libLLVMTarget.so: error: undefined reference to ‘llvm::TargetInstrInfo::getOperandLatency(llvm::InstrItineraryData const*, llvm::MachineInstr const*, unsigned int, llvm::MachineInstr const*, unsigned int) const’
clang-3: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/opt] Error 1
make[1]: *** [tools/opt/CMakeFiles/opt.dir/all] Error 2
make: *** [all] Error 2

Is anyone else getting this outcome?

  • Marc
#2

Marc,

Revision numbers are more useful than "last two days". Tobias reported a problem last night. I've committed a few changes hoping to make the situation better. But I haven't been able to verify the problem because my shared-lib build fails immediately as follows:

cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_C_COMPILER=/usr/bin/clang -DLLVM_ENABLE_ASSERTIONS=1 ...

Linking CXX shared library ../libLLVMTableGen.dylib
Undefined symbols for architecture x86_64:
  "llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >::setInitialValue(std::string const&)", referenced from:
      void llvm::cl::initializer<char [2]>::apply<llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> > >(llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >&) const in Main.cpp.o

If anyone can reproduce the errors that Marc reported above, contact me directly so we can figure out a fix. Until then, I'll continue trying to reproduce it.

-Andy

#3

Andrew,

What every bit of code committed to trunk this afternoon did the trick. Compiles cleanly against gcc and clang-trunk from a few days prior.

I’ll be precise on trunk revisions in the future as well as a more in-depth analysis of what trips, and when it trips. If I knew the inner workings of LLVM/Clang I’d be of much greater use.

Thank you for the fixes.

  • Marc