New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to use LLVM 16 as a library from apt.llvm.org #58075
Comments
@akyrtzi. This seems to be something try to be fixed here: https://reviews.llvm.org/D132033 but that got reverted because it breaks clangd build. We need to take a look at external builds since that is not tested by our CI system. Do you have a reproducing steps for your problem, like where to get the package and how the packages are built? |
My initial impression is that the clangdRmoteIndexProto is configured but not built/shipped. |
Sounds about right. I don't know how the packages are built, but they come from https://apt.llvm.org; its setup is described there. Here's a minimal-ish "repro": https://github.com/rymiel/llvm-58075-repro |
@rymiel does it fix the issue if you change |
I think My change kind of sink |
Note that this particular error seems a bit different that the error |
I see. I found where the package is built, probably here: https://llvm-jenkins.debian.net/view/Ubuntu%20Jammy/job/llvm-toolchain-jammy-binaries/ Looks like the missing library is built (and it should be part of the |
I assume the example should use The package list is basically here: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/11/debian/llvm-X.Y-dev.install.in So the name |
Maybe we just be more flexible and do this: https://reviews.llvm.org/D135712 |
FWIW this seems like it's the wrong direction to me. This proto is part of clangd, which it not part of llvm (as opposed to llvm-project). Ideally it'd be possible to write a CMake macro without having to couple it to either "ships as part of llvm" or "ships as part of clang", but maybe it isn't. This library certainly shouldn't be built or exported as part of LLVM. If the change was doing this, quite likely I didn't understand it :-(
Sorry, I'm not sure exactly what you mean, can you be more specific?
This dumps a bunch of implementation details into every callsite, we lose a lot of the value of the build rule :-( If we can't write a rule that works well for both llvm and clang libraries, I'd probably prefer having |
I don't think the original layering is correct since referring |
Ah, got it. Agree, sorry about that (the original commit was generic using
Sure (nit: While we're worried about layering, the former should go in |
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Use `add_llvm_protos_library` and `add_clang_protos_library` to decide which layer is the library exported. Fixes: llvm#58075 Differential Revision: https://reviews.llvm.org/D135712
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Use `add_llvm_protos_library` and `add_clang_protos_library` to decide which layer is the library exported. Fixes: llvm#58075 Differential Revision: https://reviews.llvm.org/D135712
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Use `add_llvm_protos_library` and `add_clang_protos_library` to decide which layer is the library exported. Fixes: llvm#58075 Differential Revision: https://reviews.llvm.org/D135712
Thank you a lot for looking into this, unfortunately I cannot test if it's been fixed for apt.llvm.org because it appears the builds for LLVM 16 have been failing for ~week. I assume this is know about @sylvestre ? |
yeah, some various regressions with openmp and other things lately :/ |
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Use `add_llvm_protos_library` and `add_clang_protos_library` to decide which layer is the library exported. Fixes: llvm#58075 Differential Revision: https://reviews.llvm.org/D135712
Thank you everyone, this specific problem seems to be fixed! However #58317 remains for 16 |
Installing the
llvm-dev
package for LLVM 16 from apt.llvm.org, then attempting to use LLVM as a CMake library usingfind_package(LLVM 16 REQUIRED CONFIG)
always fails with the following error:I don't have enough cmake knowledge to be sure of the cause, but i assume this to be caused by (or related to) https://reviews.llvm.org/D131593.
Since that changed
generate_protos
to calladd_llvm_library
, andgenerate_protos
is used by https://github.com/llvm/llvm-project/blob/894c0e94f9c62413feef88fd577c430839abaea7/clang-tools-extra/clangd/index/remote/CMakeLists.txt, those now appear in theLLVM_AVAILABLE_LIBS
list in/lib/cmake/llvm/LLVMConfig.cmake
.This can be manually verified by the existence of those entries in the cmake file, which were not there in previous versions.
Note that installing clangd alongside LLVM also fails, presumably because the LLVM cmake config is looking for packages under
/usr/lib/llvm-16/
, but clangd is installed somewhere else.I am using
ubuntu-22.04
(jammy) in GitHub actions (of which I can provide the build file in case further reproduction is required), but I was able to note the existence ofclangd
entries in the LLVM config for other distributions as well.The text was updated successfully, but these errors were encountered: