Как узнать версию glibc linux

Benohead’s Software Blog

Linux: Check the glibc version

If you need to check which version of the GNU C library (glibc) is used on you Linux system, whether it’s to check whether you are affected by the GHOST vulnerability or you need to install a software requiring at least a certain version but not checking it on build/installation, the easiest way is to use ldd which comes with glibc and should in most cases have the same version:

If you know you might have patched the system to use a different version of ldd and know that its version doesn’t match the glibc version, you have two additional ways to find out the glibc version:

1. Check the version of the installed glibc rpm package
2. Check the version of the used libc.so file

The second way is a little bit more difficult. You first have to find which libc.so file is being used by a known program e.g. netstat:

You can also find the libc.so file used with the following command:

So we now know that /lib64/libc.so.6 is being used and we just need to get it’s version:

If you want to determine the glibc version from C program and not from a shell script, you can just use something like this:

You can then compile it and execute it like this to get the glibc version:

Of course, if your C file is not called glibc_version.c, you’ll have to use the name you’ve actually used in the gcc arguments.

Since your current shell is probably also using glibc, you can also find out which libc library it has loaded by using the following command:

Источник

Просмотр информации о библиотеке Linux / исполняемой версии

В Windows EXE и DLL имеют информацию о версии, включая, по крайней мере, следующие поля:

1. версия файла
2. версия продукта
3. внутреннее имя
4. наименование товара
5. авторское право

В Linux Library / Исполняемый файл:

• Какие поля присутствуют?
• Как просмотреть такую ​​информацию?
• Какие инструменты / библиотеки читать?

Информация о версии явно не сохраняется в файле ELF . У вас есть название библиотеки, в soname которую входит основная версия. Полная версия обычно хранится как часть имени файла библиотеки.

Если у вас есть, скажем libtest.so , библиотека , то у вас обычно есть:

• libtest.so.1.0.1 — сам файл библиотеки, содержащий полную версию
• libtest.so.1 — Ссылка на libtest.so.1.0.1 , имеющая то же имя, что и soname
• libtest.so — Симлинк, libtest.so.1 используемый для ссылки.

В файле библиотеки libtest.so.1.0.1 будет SONAME динамическая секция, которая будет называть эту библиотеку вызываемой libtest.so.1 . Когда вы связываете программу с этой библиотекой, связанная программа будет хранить входящую soname библиотеку NEEDED в динамическом разделе.

Если вы хотите проверить, что именно находится в ELF-файле, вы можете попробовать запустить:

где elffile может быть библиотека исполняемого файла.

Если вы просто хотите получить версию библиотеки, вы можете поиграть с:

AFAIK, такой информации нет (по крайней мере, по умолчанию) в исполняемых файлах.

Или вы можете положиться на саму программу или свою систему упаковки, как писал Рахул Патил.

Источник

Как я могу сделать ссылку на конкретную версию glibc?

Когда я компилирую что-то на своем ПК с Ubuntu Lucid 10.04, оно связывается с glibc. Lucid использует glibc версии 2.11. Когда я запускаю этот двоичный файл на другом компьютере с более старой версией glibc, команда не сообщает, что glibc 2.11 .

Насколько мне известно, в glibc используется управление версиями символов. Могу ли я заставить gcc ссылаться на определенную версию символа?

В моем конкретном использовании я пытаюсь скомпилировать кросс-инструментальную цепочку gcc для ARM.

Вы правы в том, что glibc использует управление версиями символов. Если вам интересно, реализация управления версиями символов, представленная в glibc 2.1, описана здесь и является расширением схемы управления версиями символов Sun, описанной здесь .

Один из вариантов — статически связать ваш двоичный файл. Это, наверное, самый простой вариант.

Вы также можете собрать свой двоичный файл в среде сборки chroot или с помощью кросс-компилятора glibc- new => glibc- old .

Согласно сообщению в блоге http://www.trevorpounds.com Связывание со старыми версиями символов (glibc) , можно принудительно связать любой символ с более старым, если он действителен, используя тот же .symver псевдо -op, который используется в первую очередь для определения версионных символов. Следующий пример взят из сообщения в блоге .

В следующем примере используется реальный путь glibc, но проверяется, что он связан с более старой версией 2.2.5.

Ссылка на -static . Когда вы связываете с -static, компоновщик встраивает библиотеку внутри исполняемого файла, поэтому исполняемый файл будет больше, но он может быть выполнен в системе со старой версией glibc, потому что программа будет использовать свою собственную библиотеку вместо библиотеки системы .

Настройка 1: скомпилируйте свой собственный glibc без выделенного GCC и используйте его

Поскольку кажется невозможным обойтись только с помощью хаков управления версиями символов, давайте сделаем еще один шаг и скомпилируем glibc сами.

Эта установка может работать и выполняется быстро, поскольку она не перекомпилирует всю цепочку инструментов GCC, а только glibc.

Но это не так надежно , как он использует такие объекты хоста C во время выполнения , как crt1.o , crti.o и crtn.o обеспечивается Glibc. Это упоминается по адресу: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location Эти объекты выполняют раннюю настройку, на которую полагается glibc, поэтому я не удивлюсь, если что-то выйдет из строя. и потрясающе тонкие способы.

Для более надежной настройки см. Настройка 2 ниже.

Скомпилируйте glibc и установите локально:

Настройка 1: проверьте сборку

Скомпилируйте и запустите с test_glibc.sh :

Программа выводит ожидаемые:

поэтому я удалил это.

ldd вывод подтверждает, ldd что только что созданные библиотеки и используются должным образом:

В gcc выходные показывает компиляции отладки , которые были использованы мои объекты во время выполнения хост, который плохо , как уже упоминалось ранее, но я не знаю , как работать вокруг этого, например , он содержит:

Настройка 1: изменить glibc

Теперь давайте изменим glibc с помощью:

Затем перекомпилируйте и переустановите glibc, перекомпилируйте и повторно запустите нашу программу:

и мы видим hacked напечатанные несколько раз, как и ожидалось.

Это еще раз подтверждает, что мы на самом деле использовали скомпилированную glibc, а не хост.

Проверено на Ubuntu 18.04.

Вариант 2: первоначальная настройка кросс-стула-NG

Это является альтернативой установке 1, и это наиболее правильная установка я достиг далеко: все правильно, насколько я могу наблюдать, в том числе во время выполнения C объекты , такие как crt1.o , crti.o , и crtn.o .

В этой настройке мы скомпилируем полную специализированную цепочку инструментов GCC, которая использует желаемый glibc.

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

crossstool-NG — это набор сценариев, который загружает и компилирует для нас все из исходников, включая GCC, glibc и binutils.

Да, система сборки GCC настолько плоха, что для этого нужен отдельный проект.

Эта установка не идеальна только потому, что crossstool-NG не поддерживает сборку исполняемых файлов без дополнительных -Wl флагов , что кажется странным, поскольку мы создали сам GCC. Но вроде все работает, так что это только неудобства.

Получите crossstool-NG и настройте его:

Единственная обязательная опция, которую я вижу, — это согласование с версией ядра вашего хоста для использования правильных заголовков ядра. Найдите версию ядра вашего хоста с помощью:

который показывает мне:

так что menuconfig я делаю:

поэтому я выбираю:

которая является первой равной или более старой версией. Он должен быть старше, поскольку ядро ​​обратно совместимо.

Теперь вы можете строить с помощью:

а теперь подождите от 30 минут до двух часов для компиляции.

Настройка 2: дополнительные конфигурации

То, .config что мы создали, ./ct-ng x86_64-unknown-linux-gnu имеет:

Чтобы изменить это, menuconfig выполните:

сохраните .config и продолжите сборку.

Или, если вы хотите использовать свой собственный источник glibc, например, чтобы использовать glibc из последней версии git, действуйте следующим образом :

• Paths and misc options
  • Try features marked as EXPERIMENTAL : установить в значение true
• C-library
  • Source of glibc
    • Custom location : скажи да
    • Custom location
      • Custom source location : указать каталог, содержащий ваш исходный код glibc

где glibc был клонирован как:

Установка 2: проверьте это

После того, как вы создали нужный набор инструментов, протестируйте его с помощью:

Кажется, все работает как в настройке 1, за исключением того, что теперь использовались правильные объекты среды выполнения:

Настройка 2: неудачная попытка эффективной перекомпиляции glibc

Как поясняется ниже, это невозможно с crossstool-NG.

Если вы просто перестроите;

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

Если мы сделаем:

он дает хороший обзор этапов сборки:

следовательно, мы видим, что есть шаги glibc, переплетенные с несколькими шагами GCC, в первую очередь libc_start_files предшествующими шагам cc_core_pass_2 , которые, вероятно, являются наиболее дорогостоящими шагами вместе с cc_core_pass_1 .

Чтобы построить только один шаг, вы должны сначала установить .config опцию «Сохранить промежуточные шаги» для начальной сборки:

• Paths and misc options
  • Debug crosstool-NG
    • Save intermediate steps

а затем вы можете попробовать:

Однако обратите внимание, что перезапуск на промежуточном этапе сбрасывает каталог установки до состояния, которое было на этом этапе. Т.е. у вас будет пересобранная libc, но не будет окончательного компилятора, построенного с этой libc (и, следовательно, не будет компиляторных библиотек, таких как libstdc ++).

и, по сути, по-прежнему делает перестройку слишком медленной, чтобы ее можно было реализовать в разработке, и я не вижу, как это преодолеть без исправления crossstool-NG.

Кроме того, начиная с libc шага, похоже, не было повторного копирования источника Custom source location , что еще больше сделало этот метод непригодным для использования.

Бонус: stdlibc ++

На мой взгляд, самое ленивое решение (особенно если вы не полагаетесь на новейшие функции C / C ++ или новейшие функции компилятора) еще не упоминалось, поэтому вот оно:

Просто создайте систему с самой старой GLIBC, которую вы все еще хотите поддерживать.

В настоящее время это довольно просто сделать с помощью таких технологий, как chroot, KVM / Virtualbox или docker, даже если вы действительно не хотите использовать такой старый дистрибутив непосредственно на любом компьютере. В деталях, чтобы сделать максимально переносимый двоичный файл вашего программного обеспечения, я рекомендую выполнить следующие шаги:

Просто выберите свой яд в виде песочницы / виртуализации / . чего угодно, и используйте его, чтобы получить себе виртуальную старую версию Ubuntu LTS и скомпилировать с помощью gcc / g ++, которая есть по умолчанию. Это автоматически ограничивает ваш GLIBC тем, который доступен в этой среде.

Избегайте зависимости от внешних библиотек за пределами основных: например, вы должны динамически связывать системные вещи нижнего уровня, такие как glibc, libGL, libxcb / X11 / wayland, libasound / libpulseaudio, возможно GTK +, если вы это используете, но в противном случае предпочтительнее статически связывать внешние libs / отправьте их, если можете. В частности, в большинстве случаев автономные библиотеки, такие как загрузчики изображений, мультимедийные декодеры и т. Д., Могут вызывать меньше поломок в других дистрибутивах (поломка может быть вызвана, например, если они присутствуют только где-то в другой основной версии), если вы отправляете их статически.

При таком подходе вы получаете двоичный файл, совместимый со старым GLIBC, без каких-либо ручных настроек символов, без выполнения полностью статического двоичного файла (который может сломаться для более сложных программ, потому что glibc ненавидит это и может вызвать проблемы с лицензированием для вас) и без настройки создать любую настраиваемую цепочку инструментов, любую настраиваемую копию glibc или что-то еще.

Источник

📦 Как проверить версию установленного пакета в Ubuntu/Debian

Есть много людей, которые задают вопрос: «Как мне проверить версию установленного пакета в моей системе Ubuntu/Debian?»

Как узнать версии пакетов, доступные в операционной системе Ubuntu/Debian Linux ?

В Linux все приложения распространяются в виде пакетов, которые представляют собой не что иное, как файлы, связанные с системой управления пакетами.

Это руководство покажет вам несколько команд, которые можно использовать для проверки версии пакета на машине Ubuntu/Debian Linux.

Системы Linux на основе Debian поставляются с двумя основными менеджерами пакетов:

• apt – Управление пакетами из репозиториев
• dpkg – Управление пакетами, загруженными в систему. Часто в формате .deb
• aptitude можно установить и использовать аналогично apt

Чтобы проверить версию установленного пакета на вашем сервере/настольном Ubuntu, используйте любой из методов, показанных в следующих разделах.

Прежде чем начать, обновите APT-индекс вашего пакета:

Метод 1. Использование команды apt

Команда apt имеет список параметров, который можно использовать для проверки версии пакета, установленного в системе Ubuntu или Debian.

Например, чтобы проверить версию пакета curl, установленную на моем сервере Ubuntu/Debian, я бы запустил:

Чтобы увидеть все версии пакета, доступные в репозитории, передайте параметр -a.

Источник