CMake Error at cmake/modules/CMakeLists.txt

[shoober420]

I'm not sure which commit caused this, but when compiling against LLVM master branch, I get the following errors. Full logs attached.

Build Log:

CMake Error at cmake/modules/CMakeLists.txt:1 (include):
  include could not find requested file:

    ExtendPath


CMake Error at cmake/modules/CMakeLists.txt:3 (include):
  include could not find requested file:

    FindPrefixFromConfig


CMake Error at cmake/modules/CMakeLists.txt:113 (find_prefix_from_config):
  Unknown CMake command "find_prefix_from_config".

CMakeError Log:

Run Build Command(s):/usr/bin/ninja cmTC_ba7f6 && [1/2] Building CXX object CMakeFiles/cmTC_ba7f6.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_ba7f6.dir/src.cxx.o 
/usr/bin/x86_64-pc-linux-gnu-g++ -m32 -DHAS_WERROR_GLOBAL_CTORS   -DNDEBUG -O2 -flarge-source-files -w -fPIC -fno-semantic-interposition -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-pessimizing-move -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections    -Werror=global-constructors -std=c++14 -o CMakeFiles/cmTC_ba7f6.dir/src.cxx.o -c /var/tmp/portage/sys-devel/llvm-14.0.0.9999/work/llvm-14.0.0.9999_build-abi_x86_32.x86/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: '-Werror=global-constructors': no option '-Wglobal-constructors'; did you mean '-felide-constructors'?
ninja: build stopped: subcommand failed.


Source file was:
int main() { return 0; }

CMakeOutput Log:

Performing C++ SOURCE FILE Test CXX_SUPPORTS_FDATA_SECTIONS succeeded with the following output:
Change Dir: /var/tmp/portage/sys-devel/llvm-14.0.0.9999/work/llvm-14.0.0.9999_build-abi_x86_32.x86/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/ninja cmTC_b5c88 && [1/2] Building CXX object CMakeFiles/cmTC_b5c88.dir/src.cxx.o
[2/2] Linking CXX executable cmTC_b5c88

Source file was:
int main() { return 0; }

build.log - 6WV53QV2L.txt

CMakeError.log - 99FFXC737.txt

CMakeOutput.log - HMHA288ZK.txt

[jrprice]

If you're using a sparse-checkout, you'll need to add the recently added /cmake directory to your .gito/info/sparse-checkout file and update to get these additional CMake config files.

[shoober420]

@jrprice

I'm on Gentoo, using the llvm-14.0.0.9999 ebuild. I don't even know where the "sparse-checkout" file is on my system. I don't seem to have a ".git" directory in my home directory or llvm directory.

[Mystro256]

Yeah I get this issue too. The checkout is fine, the files in /cmake/modules exist, but there's some sort of cmake related bug that isn't too clear.

[h-vetinari]

Hitting this issue in conda-forge (conda-forge/llvmdev-feedstock#143), where we have until now built llvm (the subproject) only from the llvm sources (and not llvm-project as a whole).

Do I understand correctly that that's not possible anymore? Is that intentional? Should the cmake/ folder perhaps be part of the produced subproject sources?

From the POV of our build it's a regression (though we'll survive if it is declared unsupported), hence tagging @tstellar, as I cannot set milestones.

[karineek]

I also got this issue. I checked recent changes in cmake/Modules/ folder. This commit looks related to it: 44e3365.
I first tried to upgrade my Cmake from 3.16.3 (ubuntu-20 default) to 3.22.2 (newest), but this didn't solve the issue.

I used its parent commit (git checkout b99833d) to build llvm with coverage, and it seems to work (after turning off LLVM_INCLUDE_BENCHMARKS flag). It builds version 14.0.0.

[aaronpuchert]

I also got this issue. I checked recent changes in cmake/Modules/ folder. This commit looks related to it: 44e3365.

Seems likely. @Ericson2314, why put these files in cmake instead of llvm/cmake? Are there projects that don't have access to the latter?

@tstellar, if this stands I think we'll need to provide a tarball for this cmake top-level directory as well, otherwise none of the subproject tarballs are usable anymore.

[aaronpuchert]

@Ericson2314, why put these files in cmake instead of llvm/cmake?

Actually the readme answers that, but I'm not sure I understand:

The advantage of not putting these modules in an existing location like llvm/cmake/modules is two-fold:

• Since they are not installed, we don't have to worry about any out-of-tree downstream usage, and thus there is no need for stability.

Fair enough, but who is forcing us to install all files in llvm/cmake/modules? The installation already excludes GetHostTriple.cmake.

• Since they are available as part of the source at build-time, we don't have to do the usual stand-alone vs combined-build dances, avoiding much complexity.

They are not part of e.g. the llvm subproject tarball though. That used to be self-contained prior to LLVM 14.

[tstellar]

@aaronpuchert This solution exists in the main branch: https://reviews.llvm.org/D118481 Is this OK or would you prefer to have a separate cmake tarball?

[aaronpuchert]

@tstellar, thanks for pointing that out. I guess it came to late for rc1? I've worked with a separate tarball for now, but this should also work, perhaps even without changes on my side. It would give me multiple copies of that directory, but that should be bearable since it's pretty small.

[h-vetinari]

This solution exists in the main branch: https://reviews.llvm.org/D118481

That's great news, thanks! Does 32a0482 need to be marked for backport in a separate issue, or is this one enough?

[tstellar]

/cherry-pick 32a0482

[llvmbot]

Failed to cherry-pick: 32a0482

https://github.com/llvm/llvm-project/actions/runs/1913260431

Please manually backport the fix and push it to your github fork. Once this is done, please add a comment like this:

/branch <user>/<repo>/<branch>

[Ericson2314]

Glad /cmake is going in the tarballs now.

[h-vetinari]

Please manually backport the fix and push it to your github fork. Once this is done, please add a comment like this:

/branch h-vetinari/llvm-project/backport_D118481

[llvmbot]

/pull-request llvmbot#110

[h-vetinari]

@tstellar
the backport cherry-pick is ready here (leaving a comment since it missed rc2 despite being milestoned, hoping it can get into rc3).

[SupervisedThinking]

@aaronpuchert I guess a 14.0.4 will be fixed then? Or did you re-release the 14.0.3 files with paulhdk@4959d29

[aaronpuchert]

The bug is closed because by our understanding the issue has been fixed with 14.0.0, and only release candidates were affected. So what is the issue that you're seeing? The files are there, so somehow the build that you're doing doesn't pick them up.

[sbourdeauducq]

Well, just open the 14.0.3 release tarball (https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.3/llvm-14.0.3.src.tar.xz). There is a cmake folder at the top level which shouldn't be there in addition to the legitimate llvm-14.0.3.src folder, with consequences as described in this Issue. Other tarballs are also affected.

[heitbaum]

Using llvm-project (14) source now versus llvm (13), this addresses the change of packaging.

• llvm: update to 14.0.4 LibreELEC/LibreELEC.tv#6492

[tstellar]

Here is a proposed change to remove the cmake bundling from each tarball and package it separately: https://reviews.llvm.org/D125798
To me this seems like the best option for now. It will get us back into our original state with the tarballs, and then after that we can discuss other improvements like the directory names, etc.

[heitbaum]

Here is a proposed change to remove the cmake bundling from each tarball and package it separately: https://reviews.llvm.org/D125798
To me this seems like the best option for now. It will get us back into our original state with the tarballs, and then after that we can discuss other improvements like the directory names, etc.

As a packaging manager - I would ask that each .tar.gz file can discretely be built in its directory, without the .. syntax.

Whilst the updated package.mk file in LibreELEC uses the override of llvm/CMakeLists.txt - I would have preferred an CMakeLists.txt in the root directory which would have called llvm/CMakeLists.txt.

I would support NOT having 2 parent directories in the tar.gz file as llvm-14 is being shipped. If this is the need - then suggest moving both llvm (remove the version) and cmake as subdirectories in the tar.gz:llvm-14.0.3/ directory.

[aaronpuchert]

There is a cmake folder at the top level which shouldn't be there in addition to the legitimate llvm-14.0.3.src folder, with consequences as described in this Issue.

The issue described here stems from the cmake directory not being there, because the files simply didn't exist. With the directory they should be in ../cmake/Modules as in the git tree and thus should be found.

I would support NOT having 2 parent directories in the tar.gz file as llvm-14 is being shipped. If this is the need - then suggest moving both llvm (remove the version) and cmake as subdirectories in the tar.gz:llvm-14.0.3/ directory.

Isn't that #54716 instead of this issue?

[sshedi]

This issue present in llvm-15.0.1 as well.

[sshedi]

Also, this is throwing error:

llvm-project/llvm/CMakeLists.txt

Line 329 in 329fda3

set(LLVM_THIRD_PARTY_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../third-party)

With file not found which is right. There is no third-party/benchmark directory in the mentioned location in the released tarball.
I'm aware that this is a separate issue and should be discussed in a different thread but mentioning it here anyway because this is also a build regression.

Edit:
And workaround to bypass this error is using -DLLVM_INCLUDE_BENCHMARKS=OFF during cmake invocation.

[aaronpuchert]

This issue present in llvm-15.0.1 as well.

With LLVM 15 you'll have to download the cmake project tarball and unpack it alongside whatever project you're building.

Also, this is throwing error:

llvm-project/llvm/CMakeLists.txt

Line 329 in 329fda3

set(LLVM_THIRD_PARTY_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../third-party)

With file not found which is right. There is no third-party/benchmark directory in the mentioned location in the released tarball. I'm aware that this is a separate issue and should be discussed in a different thread but mentioning it here anyway because this is also a build regression.

I'm quite sympathetic, but large parts of the community don't care anymore about being able to build projects separately without checking out the whole monorepo.

Edit: And workaround to bypass this error is using -DLLVM_INCLUDE_BENCHMARKS=OFF during cmake invocation.

Exactly. Usually there is no strong reason for these interdependencies and there is a way to pull them apart.

[sshedi]

FWIW, we consume source tarballs from released assets and build rpm from it. We don't want the full repo for that purpose and we start with the assumption that released assets are good enough to build rpms without much hassle.

[NobinPegasus]

I'm very new to LLVM, cmake and all that for some project I need to modify the LLVM and build it.
But while trying to build it I and facing this exact error. Can someone explain me in simpler words why is it happening?
And how to fix it. I'm using the latest version of LLVM.

[sshedi]

I'm very new to LLVM, cmake and all that for some project I need to modify the LLVM and build it. But while trying to build it I and facing this exact error. Can someone explain me in simpler words why is it happening? And how to fix it. I'm using the latest version of LLVM.

Pass this while invoking cmake -DLLVM_INCLUDE_BENCHMARKS=OFF

[NobinPegasus]

I had actually used this pass -DLLVM_INCLUDE_BENCHMARKS=OFF but it still shows the error

[aaronpuchert]

Which error? Note that -DLLVM_INCLUDE_BENCHMARKS=OFF doesn't solve the error this issue is about, but an unrelated error.

If you see this error with the project tarballs, note that the packaging changed with LLVM 15. We're now packaging the top-level cmake directory separately, so you'll need to download that as well and unpack it next to the llvm tarball.

[NobinPegasus]

The following error
I'm using the CCR build.sh for building the LLVM

CMake Error at cmake/modules/CMakeLists.txt:1 (include):
  include could not find requested file:

    ExtendPath


CMake Error at cmake/modules/CMakeLists.txt:3 (include):
  include could not find requested file:

    FindPrefixFromConfig


CMake Error at cmake/modules/CMakeLists.txt:116 (find_prefix_from_config):
  Unknown CMake command "find_prefix_from_config".

[aaronpuchert]

I'm using the CCR build.sh for building the LLVM

Can't find the setup of the sources there, so I assume you have done that manually. Where you unpack the llvm tarball you need to unpack the cmake tarball next to it and rename the top-level directory into cmake. You can find both under e.g. https://github.com/llvm/llvm-project/releases/tag/llvmorg-15.0.7.

[NobinPegasus]

@aaronpuchert
Should I rename cmake-15.0.7.src.tar.xz to cmake? after extracting?
What you mean it extract llvm and cmake to the same directory and then rename their parent directory as cmake

[aaronpuchert]

Should I rename cmake-15.0.7.src.tar.xz to cmake? after extracting?

You should rename the directory coming out of tar xf, not the .tar.xz file.

What you mean it extract llvm and cmake to the same directory and then rename their parent directory as cmake

After extraction into the same directory you should get two directories: llvm-15.0.7.src and cmake-15.0.7.src. The latter needs to be renamed cmake. The name of the former shouldn't matter, as does the name of the parent directory.

[Gamer069]

Bug is still present in release 14.0.3.

bug is still present in release 16.0.0

[cloudren2017]

From the master branch，copy an ExtendPath.cmake and a FindPrefixFromConfig.cmake from the dir cmake/Modules/ to your relative path cmake/modules/.
Remake and solve this problem.