установка SCADA в Astra Linux SE

[Olej]

В конфигурационных файлах /etc/ld.so.conf.d нет ни одной ссылки на библиотеки каталога /usr/lib/x86_64-linux-gnu/dri, соответственно их нет и в содержимом файла ld.so.cache.

Так значит надо попробовать добавить такой файл ... после чего обязательно сделать ldconfig + проверить есть ли библиотека в кэше.

[Olej]

Алгоритм поиска каталогов для дефаултного поиска библиотек в Linux а). достаточно путанный сложный и б). многошаговый.

См. $ man ld :

Код: Выделить всё

          The linker uses the following search paths to locate required shared libraries:
           1.  Any directories specified by -rpath-link options.
           2.  Any directories specified by -rpath options.  The difference between -rpath and -rpath-link is that directories specified by -rpath options are included
               in the executable and used at runtime, whereas the -rpath-link option is only effective at link time. Searching -rpath in this way is only supported by
               native linkers and cross linkers which have been configured with the --with-sysroot option.
           3.  On an ELF system, for native linkers, if the -rpath and -rpath-link options were not used, search the contents of the environment variable "LD_RUN_PATH".
           4.  On SunOS, if the -rpath option was not used, search any directories specified using -L options.
           5.  For a native linker, search the contents of the environment variable "LD_LIBRARY_PATH".
           6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are searched for shared libraries needed by it. The "DT_RPATH"
               entries are ignored if "DT_RUNPATH" entries exist.
           7.  The default directories, normally /lib and /usr/lib.
           8.  For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of directories found in that file.
           If the required shared library is not found, the linker will issue a warning and continue with the link.

Правда, это для линкера, при построении, связывании программы. При выполнении алгоритм поиска следует той же логике, но несколько отличается.

[Olej]

Библиотеки swrast_dri.so и kms_swrast_dri.so находятся в каталоге /usr/lib/x86_64-linux-gnu/dri.

Есть ещё один такой, не совсем корректный наверное, способ подключить требуемую библиотеку к исполняемому приложению ... он помогает когда нужно связать сильно старую или сильно новую программу (проблема с версиями приложения и библиотек):
- зайдите в каталог дефаултного размещения динамических библиотек .so, с правами root, естественно...
- сделайте мягкую, софтовую ссылку на файл действительного размещения нужной вам библиотеки, что-то типа:

Код: Выделить всё

# ln -s /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so swrast_dri.so 

[Olej]

После манипуляций с библиотеками для AlphaPlatform ситуация не изменилась:

Код: Выделить всё

administrator@astra:/opt/Automiq/Alpha.HMI$ ./alpha.hmi.designer
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Unrecognized OpenGL version
Unrecognized OpenGL version

Вы ещё, не исключено, впоролись в гораздо более неприятную ситуацию:
- у вас достаточно старое, экзотическое приложение ...
- которое может быть собрано-скомпилировано со специфическими требованиями (-L... , -l...) библиотек OpenGL ...
- и ваша библиотека swrast_dri.so требуется не приложению самому, а OpenGL
Тогда нужно детально разбираться с OpenGL.
Вот здесь есть поверхностное описание как оно всё устроено: Графический стек Linux

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

P.S. Только не нужно всерьёз воспринимать там высказывания типа:

...
Можно сказать, что классический X Window System — списанный хлам.
Въезжаем в Wayland. Wayland переиспользует очень большой объём той инфраструктуры, что мы создали на замену X Window System.
...

Эти глупости написаны в 2012-м году ... "а воз и ныне там"