При сборке Wine не для личного использования, а чтобы распространять сборки, я столкнулся с проблемой. С какой реализацией OpenCL линковать? NVIDIA, AMD, Intel, Mesa? Ответ - FreeOCL!
На самом деле, не важно с чем линковаться. У всех известных мне реализаций OpenCL, сама библиотека libOpenCL.so.1 занимает что-то около 30 Кб. Оказывается, внутри этой библиотеки ничего нет. Сам OpenCL находится в другой библиотеке (например в libatiocl64.so - смотри /etc/OpenCL/vendors/*.icd для подробностей). Однако залить проприетарный драйвер в OBS-репозиторий я не могу, так как закрытый код. Остаётся только Mesa и FreeOCL
FreeOCL это софтварная реализация OpenCL, написанная на C++, и имеющая у себя в зависимостях libatomic_ops - а LLVM не имеющая. Установив в систему FreeOCL и opencl-headers, я успешно собрал Wine. Причём Wine линкуется только с OPENCL_1.0, что не помешало конечному софту, запущенному в Wine, успешно задействовать расширения 1.2 и 2.0
В общем, рекомендую всем, кто до сих пор собирает с AMD APP SDK 3.0, перейти на FreeOCL. Я попробовал скомпилировать весь известный мне OpenCL-софт при помощи FreeOCL, а затем запустить на NVIDIA и AMD - всё работает безупречно. Не падает, не отказывается стартовать, и демонстрирует ровно ту же скорость работы.
P.S. Бинарник получает зависимость от libOpenCL.so.1 (параметр -lOpenCL), а пакет RPM или DEB также получает от pkg-config ещё несколько зависимостей:
libOpenCL.so.1(OPENCL_1.0)(64bit)
libOpenCL.so.1(OPENCL_1.1)(64bit)
libOpenCL.so.1(OPENCL_1.2)(64bit)
libOpenCL.so.1(OPENCL_2.0)(64bit)
Поэтому если вы собираете пакеты, а не просто tar.gz архив с программой, рекомендую пропатчить FreeOCL патчем freeocl-0.3.6-disable-symbol-versioning.patch. В этом случае, пакет получит зависимость только от libOpenCL.so.1()(64bit). Например в моей системе в пакете NVIDIA 340.xx нет «версионинга» OpenCL, а в 390.xx он есть. Вследствие чего, пакет не хотел устанавливаться, но после force install - работал.