CMake error when configuring with CMake

Subprojects LLDB
,
1

Hello,
I’m trying to build LLDB under CYGWIN but I’m getting a strange error:

CMake Error at /home/carlo/packages/llvm/a/llvm-project/lldb/test/API/CMakeLists.txt:66 (message):
  LLDB test compiler not specified.  Tests will not run.

I configured by using the guidelines described here:
https://lldb.llvm.org/resources/build.html

LLVM and CLang have been compiled successfully.
I added some debug prints to CMakeLists.txt and I’m getting these results:

-- LLDB_DEFAULT_TEST_COMPILER=/home/carlo/packages/llvm/build.cygwin/./bin/clang.exe
-- LLDB_TEST_EXECUTABLE=/home/carlo/packages/llvm/build.cygwin/./bin/lldb.exe
-- LLDB_TEST_COMPILER=
-- LLDB_TEST_DSYMUTIL=/home/carlo/packages/llvm/build.cygwin/./bin/dsymutil.exe

Actually, I don’t understand why LLDB_TEST_COMPILER is empty but LLDB_DEFAULT_TEST_COMPILER is not.
Could somebody help me to understand what I’m doing wrong?
Thank you very much for your time.

Sincerely.

EDIT: setting LLDB_TEST_COMPILER to CMake on the command line to the value into LLDB_DEFAULT_TEST_COMPILER allowed to pass that point. However, the docs clearly says that “If you have Clang checked out, that will be used by default.” unless I have misunderstood the behaviour.

2

Yeah that have clang checked out dates from when it used to be separate repos, so it literally means did you clone the clang repo, which no longer exists. What is the full cmake command you used?

I think the text should be something like if you have clang enabled in LLVM_ENABLE_PROJECTS, now that we’re in the monorepo world.

3

I cloned the entire llvm-project repo at GitHub - llvm/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. with GIT.
Next, I created the build directory and I compiled some stuff with:

$ cmake ../a/llvm-project/llvm -G Ninja -DCMAKE_BUILD_TYPE=Release -Wno-dev -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_PROJECTS="lld;clang;bolt;polly;mlir"
$ ninja

After finished, I added lldb to the list of the projects:

$ cmake ../a/llvm-project/llvm -G Ninja -DCMAKE_BUILD_TYPE=Release -Wno-dev -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_PROJECTS="lld;clang;bolt;polly;mlir;lldb"

And here it stopped, unless I explicitely declare LLDB_TEST_COMPILER on the command line.
As you can see, I’m not doing a standalone build, but I’m compiling the all-in-one source tree.
Thanks.

4

I’ve never tried adding lldb to an existing build like that, sounds like a bug in our CMake that we don’t look at the “final” list of projects maybe just the new ones. I’ll see if I can reproduce it.

5

Doesn’t reproduce on Ubuntu using cmake 3.24.2.

You put some prints in already, I think that’s the way to figure this out. There’s not much to go wrong in lldb/test/API/CMakeLists.txt.

The only thing I can think of is maybe you had a cache file that somehow had LLDB_TEST_COMPILER set to “”, but it sounds like you started with a fresh build so that’s unlikely.

6

Did you re-use the same build directory and build artifacts when re-running CMake? Based on your conversation with David I’m leaning towards something in the CMakeCache being stale (or some other kind of state mismanagement issue).

7

I’ve sort of done this. I’ve run an initial cmake, then run ccmake or cmake-gui, then used the configure and generate options after changing LLVM_ENABLE_PROJECTS. I haven’t seen any issues doing that. But I haven’t run under CYGWIN, just Linux and Windows without CYGWIN.

9

I did more tests and I think that I have found the cause of the bug.
Actually, clang works if it’s called from the command line, but clang.exe doesn’t exist, at least when compiling the latest sources of llvm-project.
After the build process completes, I got one executable file:

clang-18.exe

and several links to this executable:

clang
clang++
clang-cl
clang-cpp

By doing a directory listing, I got these results:

lrwxrwxrwx 1 carlo carlo     12 Sep 23 15:40 clang -> clang-18.exe
lrwxrwxrwx 1 carlo carlo      9 Sep 23 15:40 clang++ -> clang.exe
lrwxrwxrwx 1 carlo carlo      9 Sep 23 15:40 clang-cl -> clang.exe
lrwxrwxrwx 1 carlo carlo      9 Sep 23 15:40 clang-cpp -> clang.exe

As you can see, clang points to clang-18.exe and this could be also ok under some circumstances.
Instead, if you look instead clang++, you will see that it points to clang.exe.
And this is the source of the problem, because clang.exe doesn’t exist.
It exists “clang”, without the “.exe” extension, not “clang.exe”.
The same for all others.
And infact, calling these symbolic links just returns an error on the console because the source file is not found.
From the command line, using clang link works because the shell ignores the extension of the executable if it exists as “.exe”.
But this does not seem the same thing for CMake stuff: LLDB_DEFAULT_TEST_COMPILER was also pointing to clang.exe and for some reasons the entry in the CMake cache was left empty.

About clang++/clang-cl/clang-cpp, I don’t know if there are some particular reasons for linking to clang instead of clang-18, if it was needed by a port or something like that.
Perhaps, this solution has the advantage that you can change all those links by changing just clang if you have multiple versions of the compiler installed.
In other words, if for example you change clang for pointing to clang-17 instead of clang-18, you won’t need to change anything else.

However, I would like to suggest to make those symbolic links with “.exe” extension appended at the end of their names.
This will fix the issue, but I’m also not sure if there are reasons for not having it.

I have to say that I tried to search where those links are created, for doing a test directly myself, but I was not able to find the right point to modify until now.
Have you some suggestions for starting?

10

To me this looks like an issue with how the symlinks are constructed for the clang binaries. If you look at llvm-project/clang/tools/driver/CMakeLists.txt, it looks like there is a list of symlinks to be constructed (the same list you’ve noticed in your explanation). Adding those symlinks happens in the CMake macro add_clang_symlink defined in llvm-project/clang/cmake/modules/AddClang.cmake. I’d start there and see if it needs adjustment for Cygwin.