У меня установлен 64-битный сервер Ubuntu 12.04 под Hyper-V. Я установил Pervasive 64-битные драйверы SQL, чтобы сценарий обновления запасов мог запускаться ежедневно (обновляет внешнюю базу данных MySQL с другого локального сервера, на котором работает программное обеспечение Exchequer / база данных PSQL).
Эти драйверы кажутся конфликтующими, как я обнаружил при попытке запустить какие-либо команды apt-get:
apt-get update
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by apt-get)
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by apt-get)
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by apt-get)
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12)
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12)
apt-get: /usr/local/psql/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12)
Любая помощь была бы замечательной.
Похоже, вы или установщик добавили /usr/local/pgsql/lib64/ к /etc/ld.so.conf или в LD_LIBRARY_PATH переменная окружения. Если это в ld.so.conf удалить его и запустить ldconfig. То же, если по умолчанию LD_LIBRARY_PATH - чек /etc/environment, общесистемные сценарии запуска, ваши .bashrc и .bash_profile и т.д., чтобы увидеть, где это могло быть добавлено.
Ужасная идея иметь несовместимый libstdc++ на пути поиска библиотеки. Если установщик Pervasive сделал это, сообщите об ошибке, это абсолютно неприемлемо и (как вы обнаружили) может сломать вашу систему.
Как только его больше не будет на пути поиска вашей библиотеки, все остальное возобновит работу, но драйверы не будут работать. Вы можете заставить их работать, запустив программу, которая их использует, со сценарием-оболочкой, который устанавливает LD_LIBRARY_PATH="/usr/local/pgsql/lib64/:${LD_LIBRARY_PATH}" но только если эти программы сами по себе не требуют libstdc++.
Скрипт-оболочка может быть таким простым, как:
#!/bin/sh
set -e
LD_LIBRARY_PATH="/usr/local/pgsql/lib64/:${LD_LIBRARY_PATH}"
/path/to/my/program "$@"
"$@" - это «магическая» переменная, которая расширяется в исходные аргументы, передаваемые сценарию оболочки. Сохраните сценарий, скажем, myprogram_wrapper.sh, редактировать /path/to/my/program чтобы указать местоположение исполняемого файла приложения, которое вы хотите запустить, и используйте chmod a+x my_program_wrapper.sh чтобы сделать его исполняемым. Затем вы можете запустить приложение с помощью ./my_program_wrapper.sh или добавьте эту оболочку в ярлыки на рабочем столе и т. д. вместо исходного приложения.
Вот как многие программы, объединенные в двоичные файлы, такие как Adobe Reader, запускают себя со своими встроенными библиотеками, не затрагивая остальную систему. Это не лучший способ (вот использовать rpath ссылки), но все в порядке.
Кто-то на форумах Pervasive предложил это исправление:
Из-за конфликтов некоторых версий мне потребовалось переместить некоторые файлы, чтобы иметь возможность запускать "apt-get" без жалоб на версии.
sudo mv /usr/local/psql/lib/libgcc_s.so.1 /usr/local/psql/lib/libgcc_s.so.1.org
sudo mv /usr/local/psql/lib/libstdc++.so.6 /usr/local/psql/lib/libstdc++.so.6.org
и после этого не запускать "sudo ldconfig"
Это работает, но после прочтения ответа @ CraigRinger я думаю, что это похоже на взлом. К сожалению, я не знаю достаточно, чтобы реализовать LD_LIBRARY_PATH исправить.