Description of problem: Upgrading to F34 broke Mesa OpenCL for me because all kernels fail to compile with "fatal error: cannot open file '/usr//usr/lib64/clc/kaveri-amdgcn-mesa-mesa3d.bc': No such file or directory". Obviously some path prefixing must have gone wrong there, as there's no "usr" in /usr. Creating such a symlink (/usr/usr → /usr) makes everything work again. Version-Release number of selected component (if applicable): libclc-11.0.0-1.fc34.x86_64 mesa-libOpenCL-21.0.3-2.fc34.x86_64 (I have no idea if this is a bug in libclc, Mesa or elsewhere. Assigning to libclc for now because it owns the directory in question.) How reproducible: At will Steps to Reproduce: 1. run "clinfo" Actual results: === CL_PROGRAM_BUILD_LOG === fatal error: cannot open file '/usr//usr/lib64/clc/kaveri-amdgcn-mesa-mesa3d.bc': No such file or directory Preferred work group size multiple (kernel) <getWGsizes:1504: create kernel : error -46> Expected results: Preferred work group size multiple (kernel) 64
same here, clover unusable for me fatal error: cannot open file '/usr//usr/lib64/clc/polaris10-amdgcn-mesa-mesa3d.bc': No such file or directory Preferred work group size multiple (kernel) <getWGsizes:1504: create kernel : error -46>
I confirm that the bug is still present with mesa-libOpenCL-21.1.3-1.fc34.x86_64. Running clinfo leads to (all the time): === CL_PROGRAM_BUILD_LOG === fatal error: cannot open file '/usr//usr/lib64/clc/polaris10-amdgcn-mesa-mesa3d.bc': No such file or directory Checking strings in the libMesaOpenCL.so.1.0.0 shows: strings /usr/lib64/libMesaOpenCL.so.1.0.0|grep clc clc/clc.L /usr//usr/lib64/clc/ which indicates the string is statically compiled in the binary.
I've done some digging through all the layers involved, and it turns out that this is really a libclc bug. /usr/lib64/pkgconfig/libclc.pc (from libclc-devel-12.0.1-1.fc34.x86_64.rpm) contains the following: includedir=/usr/include libexecdir=/usr//usr/lib64/clc … This bogus "libexecdir" is then picked up by any software built against libclc. In the case of Mesa, it gets baked into the Mesa libs as LIBCLC_LIBEXECDIR, which is then fed to clang when compiling kernels (in src/gallium/frontends/clover/llvm/invocation.cpp): clang::CodeGenOptions::BitcodeFileToLink F; F.Filename = LIBCLC_LIBEXECDIR + dev.ir_target() + ".bc"; Fixing this will thus require first fixing the bogus path in libclc-devel and then rebuilding all affected software (including mesa) against the fixed version. Until that happens, everyone affected will have to create a symlink from /usr/usr to /usr as a workaround.
And this is actually a bug in the Fedora spec for libclc, not an upstream bug. libclc.spec does the following in %build: %cmake -DCMAKE_INSTALL_DATADIR:PATH=%{_libdir} However, %_libdir is an absolute path (/usr/lib64), while CMAKE_INSTALL_DATADIR is supposed to be relative to the prefix (its default value is "share"). libclc.pc.in then uses it as follows: libexecdir=@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_DATADIR@/clc So the CMAKE_INSTALL_PREFIX of "/usr" and the CMAKE_INSTALL_DATADIR of "/usr/lib64" get combined to the final bogus path.
*** Bug 1971341 has been marked as a duplicate of this bug. ***
FEDORA-2021-731fcc44d6 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-731fcc44d6
FEDORA-2021-8298ef75e9 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8298ef75e9
FEDORA-2021-8298ef75e9 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8298ef75e9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8298ef75e9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-731fcc44d6 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-731fcc44d6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-731fcc44d6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The bogus path is now gone from libclc-devel. However, everything that BuildRequires: libclc-devel should now be rebuilt to pick the change up. Shall I file a separate Mesa bug for that, reassign this one, or will someone take care of finding all the affected packages?
FEDORA-2021-8298ef75e9 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-731fcc44d6 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days