Устранение ошибки "libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported" при запуске 1С на Debian 13.
При попытке запуска на исполнение платформы 1с в среде debian 13.2 без возникает ошибка
"libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported."
Проверено на платформах версий:
8.3.27.1936
8.5.1.1150
Что, по-видимому, вызвано использованием в компонентах платформы различных версий библиотеки libsoup. Или для одного компонента указывается необходимая версия, а для другого без указания конкретной версии, и тогда используется наиболее старшая из доступных.
При установке Debian 13.2 одновременно установлены версии
libsoup-2.4
libsoup-3.0
Советы по удалению одной из версий приводят к нарушению целостности системы -- для работы системы нужны обе версии.
Чтобы устранить ошибку, необходимо заставить 1С использовать только одну из версий библиотеки libsoup.
Это можно сделать, создав символическую ссылку на выбранную основной версию.
Для моего случая (сочетания версий библиотек), посредством команды: sudo ln -s libsoup-3.0.so.0.7.4 libsoup-2.4.so.1
Есть великолепная инструкция по сборке постгреса из сорцов от Алмаза Шарипова https://almaz-sharipov.ru/article/linux-1c/pg1c, низкий ему поклон.
Но с июня 2025 у 1С что-то внутре cломалось: ейные девопсы затупили и вендор начал выкладывать архив с битым файлом dsc.
Статья рассматривает следующие вопросы для ОС Debian:
- правильную установку компилятора gcc для сборки компонент из шаблона VNCOMP82, а также скрипт для
обновления до версии gcc 3.4.6 (минимально рекомендуемая версия) под старые версии debian 3.x
- актуальную ссылку на учебный диск фирмы 1С (свободная лицензия), который содержит шаблоны для
внешних компонент по технологии NATIVE.
- доработка шаблона VNCOMP82 под debian 64 bit.
Использованные в статье скрипты можно использовать для настройки основного окружения. В статье не рассматриваются вопросы, связанные с установкой дистрибутивов.
Расскажем, какие инструменты помогают анализировать и адаптировать код под Linux, приведем реальные примеры рефакторинга и разберем этапы тестирования перед переходом. А также представим чек-лист для проверки готовности конфигурации к работе на серверной платформе 1С под Linux.
Проблема: При переходе с Windows на Linux многие сталкиваются с затруднениями при настройке аутентификации ОС в веб-клиенте 1С через Apache 2.4 (Debian).
Решение: Команда Magnit Tech (Центр экспертизы 1С и Сопровождение 1C) разработала готовую инструкцию по настройке веб-клиента 1С на Debian 12 с поддержкой как Windows, так и Linux-серверов.
Экономьте время — внедряйте проверенное!
Благодаря Ansible процесс развертывания и тонкой настройки сервера 1С на Linux можно полностью автоматизировать. В статье расскажем, как с помощью Ansible-плейбуков быстро и без ошибок подготовить инфраструктуру для работы 1С:Предприятие. Разберемся, как подготовить WSL для локального тестирования Ansible-сценариев перед их запуском на реальных серверах. Рассмотрим автоматизированное создание виртуальных машин с помощью Ansible, которое значительно ускоряет развертывание инфраструктуры. На практическом примере покажем, как дорабатывать роли в плейбуках для адаптации под конкретные задачи. Уделим внимание оптимизации Linux-сервера для 1С: настройке ОС, установке необходимых зависимостей и параметров для стабильной работы. Разберем процесс установки платформы 1С, настройки службы и логирования, а также интеграцию систем мониторинга (Zabbix и других) для контроля состояния сервера в реальном времени.
В современных Windows 10 и 11 можно использовать WSL (Windows Subsystem for Linux) для запуска Linux окружения. Возникает соблазнительная мысль: может, PostgreSQL и сервер 1С запустить в WSL. Или даже хуже: в Docker на WSL. Знал бы, что будет сложно - даже не начинал :)
Сложность кроется в том, что WSL это не полноценные виртуалки, а легковестные контейнеры Hyper-V с особенностями сети и GUI. Из плюсов, наверно, только размер и скорость запуска.
Столкнулся с той же проблемой на Ubuntu 24.04.
Предложенный трюк не понравился тем, что подменяется системная библиотека, которая может потребоваться другим приложениям.
Подробности
Решил подробно разобраться с вопросом. Проблема хорошо описана в статье
Summary
libsoup 3 is a new API version of libsoup that provides support for HTTP/2.
Unfortunately, it is incompatible with libsoup 2. To avoid misbehavior,
applications will crash on startup if linked to both libsoup 2 and libsoup 3
at the same time.
То есть, любое приложение, которое одновременно зависит от библиотек
libsoup-2 и libsoup-3 будет аварийно завершаться.
Получается, что 1cv8 косвенно зависит от библиотеки libwx_gtk3u-3.0.so.0,
которая в свою очередь непосредственно зависит от libsoup-2.4.so.1
и косвенно от libsoup-3.0.so.0. Подменив libsoup-2.4.so.1 библиотекой
libsoup-3.0.so.0 с помощью символической ссылки, мы решаем проблему.
По крайней мере в тех сценариях, которые мне встречались. Но кто знает,
может быть при каком-то сценарии в приложении всё же вызывается метод
из библиотеки libsoup-2.4.so.1.
Можно ли подменить библиотеку не на системном уровне, а локально,
например в папке, в которой расположен исполняемый файл 1cv8?
Раньше можно было. В Ubuntu 20.04 помогало выполнение команд
$ cd /opt/1cv8/x86_64/8.3.27.1859
$ sudo ln -s /lib/x86_64-linux-gnu/libsoup-3.0.so.0 libsoup-2.4.so.1
Почему это работало? Процесс поиска файла динамической библиотеки хорошо описан в статье
When executing a program, I guess its NEEDED libraries are loaded one by one,
and their NEEDED libraries are also loaded, in some breadth first manner,
as said in this SO post. It can be confirmed via multiple ways,
either by reading the ELF format yourself
or using external tools like ldd as shown in the previous SO post.
What happens when a new .so file is encountered (either directly or indirectly
needed by a program) This article from Debian wiki explains very well what happens
1. the DT_RPATH dynamic section attribute of the library causing the lookup
2. the DT_RPATH dynamic section attribute of the executable
3. the LD_LIBRARY_PATH environment variable, unless the executable is setuid/setgid.
4. the DT_RUNPATH dynamic section attribute of the executable
5. /etc/ld.so.cache
6. base library directories (/lib and /usr/lib)
DT_RPATH is just RPATH extracted by readelf -d.
Показать
Посмотрим, какие значения RPATH и RUNPATH у исполняемого файла и проблемной библиотки.
Как видим, в файле 1cv8 установлен только атрибут RUNPATH, равный $ORIGIN,
а в библиотеке ни RPATH, ни RUNPATH не установлены. $ORIGIN означает папку,
в которой находится проверяемый файл. В нашем случае для файла 1cv8 -
это папка /opt/1cv8/x86_64/8.3.27.1859.
Использование и различие между RPATH и RUNPATH хорошо описаны в ответе на вопрос в stackoverflow
Using the directories specified in the DT_RUNPATH dynamic
section attribute of the binary if present. Such directories
are searched only to find those objects required by DT_NEEDED
(direct dependencies) entries and do not apply to those
objects' children, which must themselves have their own
DT_RUNPATH entries. This is unlike DT_RPATH, which is applied
to searches for all children in the dependency tree
Таким образом, в нашем случае, при условии, что не установлена переменная
LD_LIBRARY_PATH, поиск файла библиотеки libsoup-2.4.so.1 будет выполняться
только в /etc/ld.so.cache и системных папках /lib и /usr/lib.
Если бы в библиотеке libwx_gtk3u-3.0.so.0 был установлен атрибут RUNPATH,
равный $ORIGIN, то поиск зависимых библиотек осуществлялся бы и в папке,
в которой находится файл libwx_gtk3u-3.0.so.0. В этом случае можно было бы
сделать подмену библиотеки libsoup-2.4.so.1 в папке /opt/1cv8/x86_64/8.3.27.1859,
как это было в Ubuntu 20.04.
Видимо, в Ubuntu 20.04 была ошибка, и атрибут RUNPATH трактовался как RPATH,
поэтому подмена в локальной папке работала. Но разработчики Ununtu, наверно,
исправили ошибку загрузчика динамических библиотек, и поэтому такой трюк теперь не проходит.
Пойдем тогда в другую сторону. Если наше приложение фактически не зависит от библиотеки libsoup-2.4.so.1, может быть её просто удалить из списка зависимостей? К счастью, такая возможность есть. К несчастью, при этом потребуется изменение существующих файлов в поставке 1С.
Подробности
Для начала найдем все исполняемые файлы и библиотеки, у которых есть зависимость от libsoup-2.4.so.1.
Оказалось, что там системная библиотека libwebkit2gtk-4.0.so.37 слинкована с libsoup-2.4.so.1, а не с libsoup-3.0.so.0, как в Ubuntu 24.04, поэтому там проблема не возникает.
В любом случае, удаляя зависимость от libsoup-2.4.so.1, оставляя только транзитивную зависимость от актуальной библиотеки libsoup через libwebkit2gtk-4.0.so.37, мы решаем исходную проблему независимо от версии ОС.
