Bug 2299949
| Summary: | Driver::GetResourcesPath() returns the wrong resource path | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tulio Magno Quites Machado Filho <tuliom> |
| Component: | clang | Assignee: | Tulio Magno Quites Machado Filho <tuliom> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 42 | CC: | airlied, fedora-llvm-team, jchecahi, kim.grasman, kkleine, npopov, sergesanspaille, siddharth.kde, suraj.ghimire7, tbaeder, tstellar, tuliom |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| URL: | https://github.com/include-what-you-use/include-what-you-use/pull/1575 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-03-18 13:14:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tulio Magno Quites Machado Filho
2024-07-25 19:45:13 UTC
I think the this discussion from upstream might be important too: https://github.com/llvm/llvm-project/pull/97197#issuecomment-2225809257 Hmm, see also https://reviews.llvm.org/D130586 -- some of the early testing appears to have seen the same lib64 vs. lib confusion (this patch does not appear to have been merged). I wonder if that's something latent in the CMake/Driver division of responsibilities that happens to surface in Fedora's configuration? Do you have a link to Fedora's cmake configure line somewhere? This is the latest cmake call for x86_64: /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCLANG_DEFAULT_PIE_ON_LINUX=OFF -DPPC_LINUX_DEFAULT_IEEELONGDOUBLE=ON -DLLVM_PARALLEL_LINK_JOBS=1 -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_EXECUTABLE=/usr/bin/python3 -DCMAKE_SKIP_RPATH:BOOL=ON -DLLVM_LIBDIR_SUFFIX=64 -DCLANG_INCLUDE_TESTS:BOOL=ON -DLLVM_BUILD_UTILS:BOOL=ON -DLLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=../clang-tools-extra-18.1.8.src -DLLVM_EXTERNAL_LIT=/usr/bin/lit -DLLVM_LIT_ARGS=-vv -DLLVM_MAIN_SRC_DIR=/usr/share/llvm/src -DLLVM_TABLEGEN_EXE:FILEPATH=/usr/bin/llvm-tblgen -DLLVM_COMMON_CMAKE_UTILS=/usr/share/llvm/cmake -DCLANG_ENABLE_ARCMT:BOOL=ON -DCLANG_ENABLE_STATIC_ANALYZER:BOOL=ON -DCLANG_INCLUDE_DOCS:BOOL=ON -DCLANG_PLUGIN_SUPPORT:BOOL=ON -DENABLE_LINKER_BUILD_ID:BOOL=ON -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_RTTI=ON -DLLVM_BUILD_DOCS=ON -DLLVM_ENABLE_SPHINX=ON -DCLANG_LINK_CLANG_DYLIB=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF -DCLANG_BUILD_EXAMPLES:BOOL=OFF -DBUILD_SHARED_LIBS=OFF '-DCLANG_REPOSITORY_STRING=Fedora 18.1.8-3.fc41' -DCLANG_RESOURCE_DIR=../lib/clang/18 -DCLANG_CONFIG_FILE_SYSTEM_DIR=/etc/clang/ -DCLANG_DEFAULT_UNWINDLIB=libgcc Notice that we use -DCLANG_RESOURCE_DIR=../lib/clang/18 The complete log of the build is available at: https://kojipkgs.fedoraproject.org//packages/clang/18.1.8/3.fc41/data/logs/x86_64/build.log > On Rawhide and F40, this function is returning `/usr/lib64/clang/18`. > The correct path is `/usr/lib/clang/18`. Just to clarify, does it return the wrong path when used inside Clang, or when used from a project external to Clang, using Clang libraries? There is an issue of consistency (because CLANG_RESOURCE_DIR is not available to external projects) that I try to address here: https://github.com/llvm/llvm-project/pull/103388 Just want to make sure there's not additional complexities I've missed. Thanks! (In reply to Kim Gräsman from comment #4) > Just to clarify, does it return the wrong path when used inside Clang, or > when used from a project external to Clang, using Clang libraries? I didn't test it from inside Clang. But the issue was caused by not having CustomResourceDir=CLANG_RESOURCE_DIR So, your PR 103388 should solve this. > Just want to make sure there's not additional complexities I've missed. Let me test PR 103388 and confirm if it works with https://github.com/include-what-you-use/include-what-you-use/pull/1575 Kim, I confirmed that all tests from iwyu passed after applying https://github.com/llvm/llvm-project/pull/103388 to clang and https://github.com/include-what-you-use/include-what-you-use/pull/1575 to iwyu. I created a copr repository for these tests: https://copr.fedorainfracloud.org/coprs/tuliom/bz2299949/builds/ It's unclear to me which path we'll use in order to fix this issue in Fedora, i.e. applying the patch downstream or waiting for LLVM 20.0. That's because of the API change. Let's see what the rest of the Fedora LLVM Team thinks. Thank you! This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42. We ended up waiting for LLVM 20. This is now fixed in Rawhide and F42. |