CMake Error

[evmckinney9]

Hello, I have installed all the prerequisites and tried using docker as well but cannot get past this step. I'm using Ubuntu 20.04.

CMake Error at utils/benchmark/src/CMakeLists.txt:19 (add_library): No SOURCES given to target: benchmark CMake Generate step failed. Build files cannot be regenerated correctly.

output.txt

[evmckinney9]

I got the same error again now on Mac 10.12.6

[AndrewLitteken]

Are you running build.sh from the root of the repository? What version of CMake are you using?

The docker container is not yet up to date unfortunately.

[evmckinney9]

Yes I am running build.sh from the root of the repo. CMake 3.21.2.

[AndrewLitteken]

Are there any files in llvm/utils/benchmark/src besides CMakeLists.txt? And can you put that file in the thread? I haven't been able to replicate this bug.

[evmckinney9]

Yes, there are more files. I zipped what was contained in llvm/utils/benchmark/src
src_zip.zip

[AndrewLitteken]

I'm not sure what the problem is, but a potential workaround, add this to the end of the command line invocation at line 58 of build.sh:

-DLLVM_INCLUDE_BENCHMARKS=OFF

[evmckinney9]

A simple test added into CMakeList.txt

FILE(GLOB BENCHMARK_MAIN "benchmark_main.cc")
message("My test's benchmark_main: ${BENCHMARK_MAIN}")

returns empty when running ./build.sh. The error is that FILE(GLOB) is never returning anything thus the error "no sources given to the target" on the call to add_library because SOURCE_FILES is empty.

I think this is the error here documented here but I haven't dug into it yet. https://gitlab.kitware.com/cmake/cmake/-/issues/20568
Edit: I think this error is for 32-bit machines, but my computer is x86_64, also this looks like an issue that was already fixed and merged into new versions of cmake.

[AndrewLitteken]

You're right that I think something is up with FILE(GLOB ...) but that's unfortunately not really something we can control, and that aspect of the build system is in the LLVM build set-up, which makes the error a bit more opaque. However, this part of the build system hasn't been updated since we started using it in the main LLVM repository either. You might try to add ${CMAKE_CURRENT_SOURCE_DIR} in front of the *.cc sources if you want to try to get it to run. If there's an issue under the hood with relative and absolute paths that might clear it up.

But, I suspect this aspect of the project isn't super related to what you're working on and would recommend also trying the workaround to just disable this part of the build.

[evmckinney9]

Including the flag to turn benchmarks off, I now have a new flurry of error messages. I appreciate the help!

The errors look like
CMake Error at cmake/modules/AddLLVM.cmake:1566 (add_dependencies): The dependency target "llc" of target "check-all" does not exist. Call Stack (most recent call first): CMakeLists.txt:957 (add_lit_target)

output2.txt

Same results on both Ubuntu and Mac

[AndrewLitteken]

I can't quite figure out why the build system isn't finding these items but add this in the same place you added the last flag: -DLLVM_INCLUDE_TESTS=OFF

It'll just ignore the path that's triggering those warnings for now. Scaffold doesn't use the llvm-lit for anything right now so you should be fine.

If I had to guess, something is different between the readdir system call on your systems. Scaffold has only been thoroughly tested on Ubuntu 16.04 and macOS 10.14+ right now.

[evmckinney9]

Sorry to keep getting stuck.
ninja opt clang LLVMScaffold returns ninja: error: unknown target 'opt'

I'm just excluding 'opt' and will see if that lets me pass the regression test suite.

[AndrewLitteken]

I'm not sure what's happening in this case. I think CMake is not able to find the directories it needs to be able to create these as sources.

Could you try to follow the directions here: https://llvm.org/docs/GettingStarted.html, and try to run the CMake step? That might help see where the issue is if it fails.

You could also try to add "add_llvm_tool_subdirectory(opt)" to llvm/tools/CMakeLists.txt.

[evmckinney9]

Could you try to follow the directions here: https://llvm.org/docs/GettingStarted.html, and try to run the CMake step?

This runs fine.

You could also try to add "add_llvm_tool_subdirectory(opt)" to llvm/tools/CMakeLists.txt.

This allowed me to run the command ninja opt clang LLVMScaffold however I still run into errors! :(

[702/2862] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/LTOModule.cpp.o
FAILED: lib/LTO/CMakeFiles/LLVMLTO.dir/LTOModule.cpp.o 
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/user/Documents/[dir]/build/lib/LTO -I/home/user/Documents/[dir]/llvm/lib/LTO -I/usr/include/libxml2 -I/home/user/Documents/[dir]/build/include -I/home/user/Documents/[dir]/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -g  -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/LTO/CMakeFiles/LLVMLTO.dir/LTOModule.cpp.o -MF lib/LTO/CMakeFiles/LLVMLTO.dir/LTOModule.cpp.o.d -o lib/LTO/CMakeFiles/LLVMLTO.dir/LTOModule.cpp.o -c '/home/user/Documents/[dir]/llvm/lib/LTO/LTOModule.cpp'
In file included from /home/user/Documents/[dir]/llvm/include/llvm/Support/Compiler.h:18,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/Optional.h:19,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/STLExtras.h:19,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/StringRef.h:12,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/StringMap.h:16,
                 from /home/user/Documents/[dir]/llvm/include/llvm/LTO/legacy/LTOModule.h:17,
                 from /home/user/Documents/[dir]/llvm/lib/LTO/LTOModule.cpp:14:
/home/user/Documents/[dir]/llvm/include/llvm/Support/TargetSelect.h: In function ‘bool llvm::InitializeNativeTargetAsmPrinter()’:
/home/user/Documents/[dir]/build/include/llvm/Config/llvm-config.h:39:32: error: ‘LLVMInitializeX86AsmPrinter’ was not declared in this scope; did you mean ‘LLVMInitializeX86AsmParser’?
   39 | #define LLVM_NATIVE_ASMPRINTER LLVMInitializeX86AsmPrinter
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/user/Documents/[dir]/llvm/include/llvm/Support/TargetSelect.h:132:5: note: in expansion of macro ‘LLVM_NATIVE_ASMPRINTER’
  132 |     LLVM_NATIVE_ASMPRINTER();
      |     ^~~~~~~~~~~~~~~~~~~~~~
[705/2862] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/LTOCodeGenerator.cpp.o
FAILED: lib/LTO/CMakeFiles/LLVMLTO.dir/LTOCodeGenerator.cpp.o 
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/user/Documents/[dir]/build/lib/LTO -I/home/user/Documents/[dir]/llvm/lib/LTO -I/usr/include/libxml2 -I/home/user/Documents/[dir]/build/include -I/home/user/Documents/[dir]/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -g  -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/LTO/CMakeFiles/LLVMLTO.dir/LTOCodeGenerator.cpp.o -MF lib/LTO/CMakeFiles/LLVMLTO.dir/LTOCodeGenerator.cpp.o.d -o lib/LTO/CMakeFiles/LLVMLTO.dir/LTOCodeGenerator.cpp.o -c '/home/user/Documents/[dir]/llvm/lib/LTO/LTOCodeGenerator.cpp'
In file included from /home/user/Documents/[dir]/llvm/include/llvm/Support/Compiler.h:18,
                 from /home/user/Documents/[dir]/llvm/include/llvm/Support/ErrorHandling.h:17,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/Hashing.h:48,
                 from /home/user/Documents/[dir]/llvm/include/llvm/ADT/ArrayRef.h:12,
                 from /home/user/Documents/[dir]/llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h:38,
                 from /home/user/Documents/[dir]/llvm/lib/LTO/LTOCodeGenerator.cpp:14:
/home/user/Documents/[dir]/llvm/include/llvm/Support/TargetSelect.h: In function ‘bool llvm::InitializeNativeTargetAsmPrinter()’:
/home/user/Documents/[dir]/build/include/llvm/Config/llvm-config.h:39:32: error: ‘LLVMInitializeX86AsmPrinter’ was not declared in this scope; did you mean ‘LLVMInitializeX86AsmParser’?
   39 | #define LLVM_NATIVE_ASMPRINTER LLVMInitializeX86AsmPrinter
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/user/Documents/[dir]/llvm/include/llvm/Support/TargetSelect.h:132:5: note: in expansion of macro ‘LLVM_NATIVE_ASMPRINTER’
  132 |     LLVM_NATIVE_ASMPRINTER();
      |     ^~~~~~~~~~~~~~~~~~~~~~
[711/2862] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/ThinLTOCodeGenerator.cpp.o
ninja: build stopped: subcommand failed.

[akj850]

Andrew,

I've build the tool flow on various flavors of Mac, including from 10.13 to 11.5...I used homebrew/macports in different cases to build the supplementary tools like ninja. Interestingly I'm running into different issues than Evan.

I tried to build it on a fresh ubuntu 20.04 server installation and had problems with the linking stage when running the "ninja llvm-headers" command. I suspect it is related to using gold rather than ld. ubuntu bundles gold and ld in the same package. Is there a way to specify in your build flow to use /usr/bin/gold instead of /usr/bin/ld for the linker?

[AndrewLitteken]

I've build the tool flow on various flavors of Mac, including from 10.13 to 11.5...I used homebrew/macports in different cases to build the supplementary tools like ninja. Interestingly I'm running into different issues than Evan.

But was it able to correctly build still?

I tried to build it on a fresh ubuntu 20.04 server installation and had problems with the linking stage when running the "ninja llvm-headers" command. I suspect it is related to using gold rather than ld.

I tried doing this on a fresh 20.04 installation as well without installing the goldutils, and this step was able to work. I believe that this is a requirement that has carried over from the and old version of llvm, and is no longer necessary. The GNU included ld should work anyway. What errors are you getting?

ubuntu bundles gold and ld in the same package. Is there a way to specify in your build flow to use /usr/bin/gold instead of /usr/bin/ld for the linker?

The build script actually already has a flag for this if you're using linux:

cmake_flags=""
if [ "${OS}" != "Darwin" ]; then
    cmake_flags="-DLLVM_USE_LINKER=gold"
fi