gnuplot: неопределенный символ в программе C

У меня есть программа на C для построения простой гауссовой распределения. Однако, каждый раз, когда я запускаю программу, я получаю эту ошибку:

gnuplot: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE

Короче говоря: пока приложение, запускающее gnuplot, устанавливает GTK_PATH в своей среде, так как gnuplot попытается подключиться к библиотекам GTK (из-за wtx, который зависит от wxGTK – первый вызов, как сообщается strace, идет к libwx_gtk3u_core-3.2.so.0, который зависит от GTK), самый простой способ предотвратить это – настроить среду, в которой работает gnuplot, таким образом, чтобы сбойная библиотека не подключалась.

Изменить окружение, в котором работает gnuplot, можно несколькими способами, например:

1. Путем экспорта другим GTK_PATH приложением, запускающим gnuplot, или вообще не экспортируя GTK_PATH;
2. Если gnuplot запускается в среде, похожей на оболочку, явно задав окружение для gnuplot (например, путем удаления GTK_PATH или задания LD_PRELOAD в путь к версии библиотеки, которая не будет вызывать проблем)

Смотрите предлагаемые решения в конце.

Цитируя определение GTK_PATH в Запуск GTK-приложений, из документации GTK (выделение мое):

Указывает список каталогов для поиска, когда GTK ищет динамически загружаемые объекты, такие как модули, указанные с помощью GTK_MODULES, движки тем, модули методов ввода, бэкенды файловой системы и бэкенды печати.

Если путь к динамически загружаемому объекту указан как абсолютное название пути, то GTK загружает его напрямую. В противном случае GTK проходит по каталогам в GTK_PATH, за которыми следует каталог .gtk-3.0 в домашнем каталоге пользователя, а затем системный каталог по умолчанию, который составляет libdir/gtk-3.0/modules.

Когда GTK_PATH установлен, любой динамически загружаемый объект, содержащийся в каталоге, указанном в GTK_PATH, будет иметь преимущество над тем же динамически загружаемым объектом, содержащимся в ~/.gtk-3.0 и /lib/x86_64-linux-gnu/gtk-3.0.

Что, в свою очередь, означает: если версия библиотеки, найденная при проходе по GTK_PATH, вызывает проблемы, эта проблема появится; если GTK_PATH не установлен, и первая найденная версия библиотеки в ~/.gtk-3.0 или /lib/x86_64-linux-gnu/gtk-3.0 не вызывает проблем, то проблема не появится.

Что объясняет, почему unset GTK_PATH работает; на самом деле это заставляет приложение избегать сбойной версии библиотеки.

В вашем случае, проблемная версия библиотеки – это та, которая найдена в /snap/core20/current/lib/x86_64-linux-gnu.

Многие люди, кажется, сталкиваются с такого рода проблемами при запуске приложений в интегрированном терминале VSCode.

Если вы используете VSCode (но в принципе это применимо к любому приложению), у вас есть следующие решения:

1. Обновление приложения; в случае с VSCode: sudo snap refresh code
2. Если вы находитесь в канале, отличном от stable (edge / beta / candidate), переключитесь на канал stable; в случае с VSCode: sudo snap refresh code --channel=stable

Если это не сработает, если gnuplot запускается в среде оболочки (например, в случае с интегрированным терминалом VSCode), другим способом будет удалить GTK_PATH в среде оболочки:

unset GTK_PATH

Или удалить GTK_PATH только для выполнения gnuplot:

GTK_PATH= gnuplot [...]

Или установить LD_PRELOAD на путь к версии библиотеки, которая не будет вызывать проблем:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpthread.so.0 gnuplot [...]

В случае с интегрированным терминалом VSCode вы также можете удалить GTK_PATH для интегрированного терминала, добавив это в settings.json:

"terminal.integrated.env.linux": {
    "GTK_PATH": null,
},