Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1960955

Summary: Mesa OpenCL (Clover) fails to compile kernels due to bogus path /usr//usr/lib64/clc/
Product: [Fedora] Fedora Reporter: Tomáš Trnka <tomastrnka>
Component: libclcAssignee: Tom Stellard <tstellar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: fabian.deutsch, igor.raits, kartochka378, kubatknnz, lavauxg, mihai, tstellar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libclc-12.0.1-2.fc34 libclc-13.0.0~rc1-2.fc35 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-20 13:55:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomáš Trnka 2021-05-16 19:06:18 UTC
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

Comment 1 kartochka378 2021-05-31 09:44:32 UTC
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>

Comment 2 Guilhem Lavaux 2021-06-29 21:00:45 UTC
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.

Comment 3 Tomáš Trnka 2021-08-26 19:52:07 UTC
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.

Comment 4 Tomáš Trnka 2021-08-26 20:00:47 UTC
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.

Comment 5 Peter Robinson 2021-09-15 10:39:08 UTC
*** Bug 1971341 has been marked as a duplicate of this bug. ***

Comment 6 Fedora Update System 2021-09-15 14:16:16 UTC
FEDORA-2021-731fcc44d6 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-731fcc44d6

Comment 7 Fedora Update System 2021-09-15 14:16:16 UTC
FEDORA-2021-8298ef75e9 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8298ef75e9

Comment 8 Fedora Update System 2021-09-15 19:06:05 UTC
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.

Comment 9 Fedora Update System 2021-09-16 17:01:15 UTC
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.

Comment 10 Tomáš Trnka 2021-09-17 20:38:35 UTC
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?

Comment 11 Fedora Update System 2021-09-20 13:55:59 UTC
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.

Comment 12 Fedora Update System 2021-09-24 20:23:50 UTC
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.

Comment 13 Red Hat Bugzilla 2023-09-15 01:06:39 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days