При сборке 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 - работал.