| Summary: | app-eselect/eselect-opencl-1.1.0-r4: uses incorrect path to 'global' header files it installs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Patrick Lauer <patrick> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | qa |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Here, several packages looking for opencl headers failed to build, including wine and tesseract (with +opencl). I guess that other reports such as https://bugs.gentoo.org/668554 are due to this. Re-installing eselect-opencl actually fixed it, thanks! |
The eselect module has: setup_includes_symlinks \ "${DST_PREFIX}/include/CL" \ "${PREFIX}/${libdir}/OpenCL/vendors/${cl_implem}/include/CL/" \ "${PREFIX}/${libdir}/OpenCL/global/include/CL/" However, the last path does not contain headers but CL-<version> subdirectories for which the module does not account. The result is that once Mesa stopped installing its own set of headers, eselect-opencl does not update stale symlinks and the install is entirely broken. Apparently the ebuild accounts for new paths, so reinstalling it fixes it. However, what's the purpose of having eselect module in the first place if it's broken and requires workarounds in ebuilds?