На примере не поддерживаемого дистрибутива Linux и современного веб-браузера приводятся сведения, необходимые для создания среды выполнения приложений, требующих альтернативных версий системных библиотек.
Быстрое развитие информационных технологий приводит к тому, что одно за другим сменяются поколения аппаратных платформ, а программные продукты стараются не отставать в этой гонке. Однако реальность такова, что устаревшие версии операционных систем продолжают эксплуатироваться. Причины этого могут лежать в нескольких плоскостях:
- экономической — отсутствие средств на модернизацию вычислительной техники;
- технологической — нужная программа работает только на конкретной версии операционной системы;
- психологической — пользователь привык к используемому программному обеспечению, которое он хорошо изучил и функциональность которого его полностью устраивает.
В этой статье на примере популярного в свое время дистрибутива Mandriva Linux 2008 рассматриваются действия, необходимые для запуска современного веб-браузера Pale Moon.
Исследование проблемы
Получить современный веб-браузер на устаревшем Linux можно как минимум двумя способами:
- Адаптировать исходные тексты веб-браузера для работы с пакетами тех версий, которые имеются в дистрибутиве.
- Создать в установленной системе среду, которая требуется для выполнения веб-браузера.
Первый путь — самый эстетичный, но практически неосуществимый. Веб-браузер представляет собой сложный комплекс модулей, в котором каждый модуль — это отдельный проект, разработкой которого занимается независимая команда. И если разработчики приняли решение об отказе от поддержки устаревших версий операционных систем, выполнять эту работу за них чрезвычайно сложно.
Второй путь более реалистичный, тем более что он допускает два подхода:
- Обновить пакеты дистрибутива, которые не удовлетворяют требованиям современных веб-браузеров.
- Установить требуемые пакеты в качестве дополнительных и сконфигурировать веб-браузер на их использование.
Следование первому подходу может негативно отразиться на стабильности операционной системы, поскольку официальные обновления для дистрибутива уже не выпускаются, а провести всеобъемлющее тестирование системы с собранными самостоятельно пакетами практически так же сложно, как адаптировать браузер к системе.
При использовании второго подхода устанавливаемое программное обеспечение будет взаимодействовать только с веб-браузером, и стабильность системы не пострадает. В статье предпочтение отдано именно этому, более безопасному, подходу.
Динамически компонуемые программы
Программы в машинных кодах, предназначенные для выполнения в операционной системе Linux, при сборке из исходных текстов могут быть скомпонованы с вспомогательными библиотеками статически или динамически.
За загрузку динамически компонуемых программ (см. рис. 1) в операционной системе отвечает загрузчик, ссылка на который находится в файле /liMd-linux.so.2. Сам загрузчик скомпонован статически, в чем можно убедиться с помощью команды:
Для динамически компонуемых программ вывод команды file содержит текст dynamically linked (uses shared libs), например:
Посмотреть, от каких конкретно динамических библиотек зависит исполняемый файл, можно с помощью команды:
Перед выполнением динамически компонуемой программы загрузчик должен:
- загрузить код программы в оперативную память;
- отыскать файлы динамических библиотек и загрузить код модулей в оперативную память;
- исправить в загруженном коде программы ссылки на динамические модули в соответствии с их фактическим местонахождением.
По умолчанию поиск динамических библиотек, необходимых для работы программы, производится в следующем порядке (man 8 Id.so):
- в местах, указанных при компиляции программ;
- в каталогах, перечисленных в конфигурационном файле /etc/ld.so.conf, сведения из которого обрабатываются системной утилитой Idconfig и вносятся в файл двоичного формата /etc/ld.so.cache,
- 3) в стандартных системных каталогах /usr/lib и /lib.
Временно описанный порядок поиска можно изменить, указав приоритетные пути в переменной окружения LD_ LIBRARY_PATH:
Заметим, что пути, которые указаны в п. 3, записаны в файл загрузчика при его компиляции. В этом можно легко убедиться:
При сборке пакета glibc из исходных текстов для установки в нестандартном каталоге эти пути могут быть другими, что будет показано в дальнейшем.
Веб-браузер Pale Moon
Загрузим с официального веб-сайта 32-битную версию веб-браузера Pale Moon, распакуем дистрибутивный архив и попробуем его выполнить:
Браузер не запустился, а из полученного сообщения становится понятно, что ошибка произошла при инициализации системы ХРСОМ. Сообщение ELF file OS ABI invalid характерно для подсистемы glibc, когда загрузчик динамических библиотек (/lib/ld-linux.so.2) не может идентифицировать интерфейс динамической библиотеки (в данном случае libxul.so).
Причиной подобной проблемы зачастую является:
- несоответствие версии динамической библиотеки архитектуре операционной системы (в том числе попытка использования 64-битных динамических библиотек на 32-битных операционных системах);
- несоответствие версии подсистемы glibc, установленной в операционной системе, той, которая необходима для выполнения программы.
Посмотрим сведения о динамических библиотеках пакета palemoon:
Обнаружено различие в параметре OS ABI библиотеки palemoon/libxul.so (GNU/Linux) и остальных динамических библиотек (SYSV).
Спецификация SYSV традиционна для формата ELF и операционных систем семейства UNIX, тогда как соглашение OS ABI GNU/Linux было введено позже. К сожалению, загрузчик динамических библиотек, являющийся компонентом установленной в операционной системе подсистемы glibc, не смог распознать этот формат и сообщил об ошибке.
Решить возникшую проблему можно двумя способами:
- Обновить подсистему glibc используемого дистрибутива.
- Отыскать подходящую версию проблемной динамической библиотеки в поддерживаемом формате.
Второй способ проще в случае удачного поиска, но в долгосрочной перспективе может вызвать проблемы. Ведь выполняться будет уже не исходный, а модифицированный пакет веб-браузера, и после планового обновления его до новой версии может потребоваться повторная замена динамической библиотеки. Поэтому соберем подсистему glibc из исходных текстов.
Подготовка сред выполнения и сборки
Для решения поставленной в статье задачи решено задействовать три области размещения бинарных файлов:
- Штатные библиотеки дистрибутива /lib, /usr/lib и его исполняемые файлы /bin, /sbin, /usr/Ып, /usr/sbin.
- Дополнительные библиотеки $HOME/usr/lib и исполняемые файлы $HOME/usr/bin, $HOME/usr/sbin, зависимости которых не выходят за рамки этих дополнительных библиотек и стандартных библиотек из п. 1.
- Новая версия библиотеки glibc и зависящие от нее библиотеки $HOME/glibc-2.16/lib, а также связанные с этими библиотеками исполняемые файлы $НОМЕ/ glibc-2.16/Ып и $HOME/glibc-2.16/sbin.
Необходимость выделения библиотеки glibc 2.16 и зависимых от нее программ в отдельный каталог по отношению к $HOME/usr связана с существенными трудностями при конфигурировании среды сборки пакетов, зависящих от штатных библиотек дистрибутива и некоторых дополнительных библиотек (см. приложение 1). Спрятать новую версию glibc от средств разработки проще всего таким организационным методом, нежели задавать массу ключей для компилятора и компоновщика.
Файлы с исходными текстами для сборки пакетов программного обеспечения размещаются в каталоге $НОМЕ/ work. В нем создан подкаталог $HOME/work/obj для промежуточного хранения результатов сборки GCC и glibc.
Дело в том, что если большинство пакетов могут быть собраны с помощью классической последовательности команд:
./configure —prefix=$SPREFIX; make; make install
выполненных из каталога с исходными текстами, то аналогичные команды для GCC и glibc должны выполняться из пустых подкаталогов.
Для подготовки среды сборки пакетов удобно использовать файл build.env с таким содержимым:
Перед выполнением команд сборки этот файл нужно задействовать (однократно!) в сеансе терминала следующей командой:
Подготовка инструментария
Основными инструментами разработки приложений в мире Linux являются компилятор GNU GCC и утилиты GNUBlnutils, GNU Маке и GNU Autoconf . В дальнейшем изложении для сокращения текста префикс GNU будет опускаться.
Для решения задачи, поставленной в статье, нет необходимости в использовании утилит Autoconf, потому что исходные тексты всех задействованных пакетов доступны в виде версионированных tar-архивов. Версия установленной в дистрибутиве утилиты Маке не вызвала никаких нареканий со стороны конфигурационных сценариев, поэтому
тоже останется без изменений. Потребуется обновить лишь GCC и Binutils.
В первую очередь устанавливаются средства разработки, поставляемые дистрибутивом. Они объединены мета-пакетом kemel-desktop-devel-2.6.22- 1mdv.
Отдельно устанавливается компилятор Си++, который представлен пакетом gcc-с++ 422-0.RC.1 mdv2008.0. Если о нем забыть, то при сборке GCC будет выдано сообщение об ошибке:
configure: error: C++ compiler missing or inoperational
конфигуратор почему-то не обнаруживает этой проблемы, а для исправления ошибки надо удалить каталог с результатами частичной сборки, создать новый и после установки gcc-с++ заново выполнить конфигурирование.
Для сборки GCC в каталог с исходными текстами нужно распаковать вспомогательные пакеты точной и комплексной арифметики (ISL, GMP, MPFR и МРС) и создать в нем символические ссылки на версионированные папки:
Зачем нужно выделять glibc?
Возникает вопрос: «А нельзя ли для единообразия установить новую версию glibc в каталог SHOME/usr вместе со всеми дополнительными программами и библиотеками?- Давайте рассмотрим, с какими проблемами придется столкнуться при таком варианте и как их можно решать.
При сборке программы из исходных текстов компилятор записывает в исполняемый файл путь к каталогу, в котором загрузчик будет искать файлы библиотек времени выполнения (runtime libraries) в первую очередь. Как правило, это каталог $PREFIX/lib Если при конфигурировании не указывать параметр —prefix, то в качестве $PREFIX будет использовано значение по умолчанию: /usr/local
Во вновь установленном дистрибутиве каталог /usr/local/lib пуст, поэтому при запуске собранной из исходных текстов программы будет задействована библиотека /lib/libc.so.6 в соответствии с правилом поиска динамических библиотек.
Но в описываемой ситуации, когда программное обеспечение конфигурируется с параметром -prefix=$HOME/usr, при запуске исполняемых файлов будут подключаться динамические библиотеки из каталога $HOME/usr/ lib, который содержит новую версию библиотеки glibc.
Это не всегда желательно. Если, например, в такой конфигурации собрать пакет хг-52.4, который необходим для распаковки xz-архивов, то при запуске утилиты xz будет выдаваться уже знакомая ошибка:
Привязки динамических библиотек можно увидеть с помощью команды:
Причину произошедшего демонстрирует команда:
Чтобы такой ситуации избежать, нужно в команде конфигурирования указать приоритетные пути для поиска библиотек компоновщиком (man Id).
После сборки утилита запускается и работает нормально благодаря компоновке с заданными версиями динамических библиотек:
Убедиться в результативности произведенной настройки можно с помощью команды:
При сборке из исходных текстов динамических библиотек (например. libffi-3.2.1. которая необходима пакету GTX+) можно столкнуться с проблемой иного рода. Новый компилятор GCC, установленный в каталог $HOME/usr/bm, обнаруживает новую версию библиотеки glibc и собирает целевую динамическую библиотеку с присвоением ей зависимости от версии новой библиотеки:
Из сообщения видно, что для libffi.so задействуется штатная версия glibc: /lib/i686/libc.so.6. но ожидается версия не ниже дНЬс_2.7 Справиться с этой проблемой помогает указание приоритетных путей для поиска библиотек системой сборки:
Суммируя сказанное, если собираемому пакету не требуется новая версия библиотеки glibc, при конфигурировании исходных текстов перед сборкой можно создать переменную LDFLAGS со значением ‘-Wl,-rpath/ lib, -L/lib -L/usr/lib’
Это позволяет обойти многие проблемы, но, к сожалению, не все. Некоторые программы требуют дополнительные библиотеки при старой версии glibc. Сложность конфигурирования инструментов сборки для таких случаев существенно превышает эстетические неудобства от вынесения новой версии glibc в отдельный каталог.
Если не установить вспомогательные пакеты, то конфигурирование завершится с ошибкой:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and МРС 0.8.0+.
Сборку GCC нельзя производить в том же каталоге, где находятся исходные тексты пакета. Поэтому в каталоге obj создается подкаталог gcc-4.82, делается текущим, и уже из него дается команда на конфигурирование:
Ограничение списка поддерживаемых языков программирования способствует уменьшению времени сборки и занимаемого дискового пространства. После конфигурирования сборка и установка GCC производятся с помощью команд:
Сборка пакета binutils-2.24 производится по стандартной схеме, с указанием на этапе конфигурирования пути к целевому каталогу.
Сборка glibc
Основная роль библиотеки glibc — реализация интерфейса между функциями стандарта POSIX и системными вызовами ядра операционной системы. Поэтому она находится в сильной зависимости от ядра.
Если, например, в среде дистрибутива Maridriva 2008 можно без особенных проблем собрать самую современную версию компилятора GCC 82, то к выбору совместимой версии glibc нужно подходить с большой осмотрительностью, ориентируясь на период расцвета ядра версии 2.6. В результате ряда экспериментов была найдена подходящая версия для модернизации — glibc-2.16.0.
Сборку glibc рекомендуется осуществлять с указанием на заголовочные файлы самой современной версии ядра операционной системы из доступных.
В ретроспективе «современность» означает доступность на момент выпуска glibc, в рассматриваемом примере это версия 2.6.38.8 (попытка сборки антикварной версии glibc со ссылкой на заголовочные файлы ядра четвертой или даже третьей версии GNU/Linux ни к чему хорошему не приведет).
Для установки заголовочных файлов нужно распаковать архив с исходными текстами Iinux-2.6.38.8.tar.bz2, сделать создавшийся при этом каталог текущим и выполнить команды:
где значение переменной HEADERS задает целевой каталог для заголовочных файлов.
Для сборки пакета glibc. как и для GCC, нужно создать отдельный подкаталог obj/glibc-2.16.0 и сделать его текущим. После этого можно выполнять конфигурирование:
Параметр enable-kernel задает минимальную версию ядра, которая будет поддерживаться библиотекой glibc, а параметры, содержащие i686, позволяют произвести на современном компьютере сборку пакета для устаревшей архитектуры. Если в параметре with-headers указать неправильный путь, то конфигурирование может пройти успешно, но при сборке будет выведена серия сообщений об ошибках вида:
Если же в перечне флагов компилятора CFLAGS не указать опцию -02, то сборка будет прервана ошибкой:
Процесс сборки запускается командой:
Установка производится с помощью команды:
Свежесобранный загрузчик динамически компонуемых программ в качестве стандартного пути поиска динамических библиотек будет использовать единственный каталог $HOME/glibc-2.16/lib, в чем легко убедиться:
Поэтому теперь нужно создать файл $HOME/usr/etc/ld.so.conf с перечнем дополнительных путей поиска динамических библиотек:
и выполнить команду индексирования перечисленных каталогов:
Запуск программы с новой версией glibc
На данном этапе в системе установлены две версии glibc:
- поставлявшаяся вместе с дистрибутивом 2.6.1 и находящаяся в каталоге /lib (с загрузчиком динамических библиотек /lib/ld-linux.so.2 -> /lib/ld-2.6.1 .so):
- новая 2.16.0, находящаяся в каталоге $HOME/glibc-2.16/ lib (с загрузчиком динамических библиотек $НОМЕ/ glibc-2.16/lib/ld-linux.so2 -> Id-2.16.0.so).
Если сейчас попытаться запустить веб-браузер командой:
то будет выдано сообщение об ошибке:
Дело в том, что при запуске программы palemoon/ palemoon был задействован загрузчик динамических библиотек /lib/ld-2.6.1 .so. которому не знаком новый формат динамической библиотеки libm.so.6. Система не применила новую версию загрузчика из $HOME/glib-2.16/lib/ld-2.16.0.SO. потому что путь к загрузчику прописывается в исполняемом файле при компиляции и, как правило, представлен ссылкой /lib/ld-linux.so2.
Для запуска программы с помощью конкретной версии загрузчика можно воспользоваться такой командой:
В параметре —library-path прописаны приоритетные пути поиска динамических библиотек. Теперь ошибка выглядит так:
Полученное сообщение говорит о том, что системе не удалось обнаружить файл динамической библиотеки libХ11-xcb.so.1. который нужен модулю libxul.so. Это небольшая интерфейсная библиотека, которую проще всего взять в готовом двоичном виде для архитектуры i386 из дистрибутива Debian и записать файлы libХ11 -xcb.so. 1 и libХ11 -xcb.so. 1.0.0 в каталог $HOME/usr/lib. После этого попытка запуска веб-браузера palemoon прервется сообщением:
Ссылка на отсутствующий символ gdk_x11_set_sm_ clientjd говорит о том, что установленная в дистрибутиве версия библиотеки GTK+ 2.12 не соответствует минимальным требованиям веб-браузера относительно GTK+ >=2.24. Выполним установку требуемой версии GTK+.
Сборка GTK+
С учетом изложенных выше сведений сборка пакета GTK+ 2.24 из исходных текстов превращается в рутинную процедуру. Желающие могут ее повторить, предварительно установив из дистрибутива следующие пакеты:
- zlibl-devel 1.2.3-8mdv2008.0:
- libpng-devel 1.2.19-2mdv2008.0:
- Iibfreetype6-devel 2.3.5-2mdv2008.0:
- libxl 1_6-devel 1.1.3-2mdv2008.0.
- Iibxrandr2-devel 1.2.2-1 mdv2008.0.
Без последнего пакета конфигуратор GTK+ будет завершаться с сообщением об ошибке:
Перед сборкой остальных пакетов нужно сконфигурировать среду (если она еще не была сконфигурирована) с помощью файла build.env, как было описано выше. Сборка выполняется посредством классической последовательности команд:
в соответствии с деревом зависимостей:
Если у платформы, на которой выполняется сборка, нет доступа к интернету, то при конфигурировании пакета glib-2.0 нужно отключить генерацию файлов документации, указав параметр -disable-man. во избежание ошибок:
После установки GTK+ веб-браузер palemoon-28.1 успешно запускается командой:
Цель, поставленная в начале статьи, достигнута.
Запуск современных приложений может быть выполнен под управлением устаревших не поддерживаемых версий операционных систем (и наоборот), если для них будет создано необходимое окружение. С помощью приемов, которые описаны в этой статье, можно создать требуемую среду выполнения и избежать конфликтов различных версий динамических библиотек.
Приведем список тезисов, которыми предлагается руководствоваться при решении проблем, связанных с работой динамически компонуемых программ:
- Для выполнения динамически компонуемых программ операционная система задействует загрузчик динамических библиотек.
- Загрузчик динамических библиотек является частью пакета glibc и представляет собой статически скомпонованную программу.
- Путь к загрузчику на этапе компиляции программы записывается в файл с е-двоичным кодом: Лib/id-iinux.so2.
- Для запуска программы альтернативным загрузчиком нужно выполнить сам загрузчик, передав ему в качестве параметров имя запускаемой программы и приоритетные пути поиска динамических библиотек.
- Основные пути поиска динамических библиотек задаются в конфигурационном файле /etc/ld.so.conf, на основе которого с помощью команды:
строится индексный файл /etc/id.so.cache, используемый загрузчиком.
- Приоритетные пути поиска динамических библиотек могут быть заданы через переменную окружения PKG_ CONFIG_PATH
- Приоритетный путь поиска runtime-библиотек, с которыми компилятор связывает код программы, может быть изменен с помощью опции компоновщика -rpath, которая может быть передана через переменную параметров компилятора в виде:
- Порядок обхода путей системой сборки в поисках динамических библиотек может быть изменен и дополнен посредством указания:
Описанные в статье приемы и методы могут быть использованы для решения задачи запуска произвольных программ под различными операционными системами семейства Linux FOX.
Источник: журнал «Системный администратор»