gcc: Уменьшить требуемую версию libc

Я пытаюсь запустить недавно скомпилированный двоичный файл на каком-то старом 32-битном дистрибутиве RedHat.
Бинарный файл скомпилирован C (not++) на виртуальной машине CentOS 32bits, выполняющей libc v2.12.

RedHat жалуется на версию libc:

error while loading shared libraries: requires glibc 2.5 or later dynamic linker

Поскольку моя программа довольно упрощена, скорее всего, она не использует ничего нового из libc.

Есть ли способ уменьшить требования к версии libc

Ответ 1

Итак, пытаясь найти баланс между элегантностью и грубой силой, я загрузил виртуальную машину, соответствующую целевой версии ядра, и, следовательно, исправил проблемы с библиотекой.
Все это (скачать + yum install gcc) заняло менее 30 минут.

Ссылки: виртуальные машины, таблица сопоставления версий ядра

Ответ 2

Непроверенное возможное решение

Что такое "ошибка при загрузке разделяемых библиотек: требуется ли glibc 2.5 или более поздний динамический компоновщик"?

Причиной этой ошибки является динамический двоичный файл (или одна из его зависимых разделяемых библиотек), которую вы хотите запустить, имеет только раздел.gnu.hash, но ld.so на целевой машине слишком стар, чтобы распознать.gnu.hash; он распознает только раздел старой школы.hash.

Обычно это происходит, когда динамический двоичный файл строится с использованием новой версии GCC. Решение состоит в том, чтобы перекомпилировать код с помощью опции командной строки компилятора -static (для создания статического двоичного файла) или следующей опции:
-Wl,--hash-style=both
Это сообщает редактору ссылок ld создать разделы.gnu.hash и.hash.

Согласно документации ld здесь, раздел старой школы.hash является значением по умолчанию, но компилятор может переопределить его. Например, GCC (версия 4.1.2) на сервере RHEL (Red Hat Enterprise Linux) версии 5.5 имеет следующую строку:
$ gcc -dumpspecs
....
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu   %{shared:-shared}   ....
                                                                   ^^^^^^^^^^^^^^^^
...
Для получения дополнительной информации см. Здесь.

Ответ 3

У меня уже была такая же проблема, пытаясь скомпилировать небольшой инструмент (я написал) для старой машины, для которой у меня не было компилятора. Я скомпилировал его на обновленной машине, и для запуска бинарного файла требуется, по крайней мере, GLIBC 2.14.

Сделав дамп двоичного файла (с xxd), я нашел следующее:

....
5f64 736f 5f68 616e 646c 6500 6d65 6d63  _dso_handle.memc
7079 4040 474c 4942 435f 322e 3134 005f  [email protected]@GLIBC_2.14._
....

Таким образом, я заменил вызовы memcpy в моем коде вызовом домашней memcpy, и зависимость с glibc 2.14 волшебным образом исчезла.

Извините, я не могу объяснить, почему это сработало, или я не могу объяснить, почему это не сработало до модификации.

Надеюсь, это помогло!