Двоичная совместимость между дистрибутивами Linux

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

Я работаю с API, написанным на C одним из наших деловых партнеров и предоставленным нам в виде двоичного файла .so, созданного на Fedora 11. Мы тестировали API на машине разработки Fedora 11 без проблем. Однако, когда я пытаюсь установить связь с API на целевой платформе нашего клиента, которой является SuSE Enterprise 10.2, я получаю сообщение об ошибке «Формат файла не распознан».

Команды, которые также являются частью пакета binutils, такие как objdump или nm, выдают ту же ошибку формата файла. Команда «файл» показывает мне:

ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped

и команда "ldd" показывает:

ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1'
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1)
[dependent library list]

Я предполагаю, что это связано с несовместимостью между библиотеками C на двух платформах, проблема в том, что код был скомпилирован для новой версии glibc и т. д., чем та, которая доступна на SuSE 10.2. Я публикую этот вопрос на тот случай, если есть способ скомпилировать код на платформе нашего партнера Fedora 11 таким образом, чтобы он также работал на SuSE 10.2.


c linux compiler-construction binary-compatibility
person gareth_bowles    schedule 20.11.2009    source источник
comment
на той же архитектуре? (i386 != amd64)   -  person elmarco    schedule 20.11.2009
comment
Я должен был упомянуть, что платформа сборки и целевая платформа SuSE 10.2 — это x86_64.   -  person gareth_bowles    schedule 20.11.2009
comment
Вы проверяете формат файла с помощью objdump или просто выполняете .so (да, это возможно). Это будет ELF, потому что используется с каменного века. Если у вас несовместимая версия libc, вы получите сообщение об ошибке, которое говорит именно об этом, поэтому ваше предположение, скорее всего, неверно, и проблема, вероятно, в чем-то другом.   -  person Gunther Piez    schedule 20.11.2009
comment
На самом деле, objdump, запущенный на SuSE, выдает ту же ошибку, что и компоновщик. Я отредактировал вопрос, чтобы отразить это и показать вывод команд file и ldd, которые действительно работают.   -  person gareth_bowles    schedule 21.11.2009

Ответы (6)


arrow_upward
3
arrow_downward

Я думаю, что хитрость заключается в том, чтобы создать разновидность Linux с самыми старыми версиями ядра и библиотеки C любой из платформ, которые вы хотите поддерживать. В моей работе мы используем Debian 4, что позволяет нам официально поддерживать Debian 4 и выше, RedHat 3,4,5, SuSE 10, а также различные другие дистрибутивы (SELinux и т. д.) неофициальным образом.

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

(редактировать) Я должен упомянуть, что мы используем компилятор по умолчанию, который поставляется с Debian 4, который, я думаю, является GCC 4.1.2. Установка более новых версий компилятора, как правило, значительно ухудшает совместимость.

person Matt T    schedule 20.11.2009

arrow_upward
3
arrow_downward

У Windows есть проблемы с совместимостью между различными версиями, пакетами обновления, установленными SDK и DLL в целом (DLL Hell, кто-нибудь?). Linux не застрахован от подобных проблем.

Проблемы совместимости, которые я видел, включают:

  • Изменения в библиотеке времени выполнения
  • Изменения в библиотеке ссылок
  • Изменения ядра
  • Изменения в технологии компилятора (например, версии gcc до и после EGCS. Это может быть вашей проблемой).
  • Проблемы с упаковщиком (RPM против APT)

В вашем конкретном случае я бы попросил их сделать «gcc -v» в своей системе и сообщить вам номер версии gcc. Сравните это с тем, что вы используете.

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

person T.E.D.    schedule 20.11.2009

arrow_upward
3
arrow_downward

Вы можете использовать инструмент Проверка приложений Linux ([ 1], [2], [3]), чтобы решить проблемы совместимости приложения между дистрибутивами Linux. Он проверит ваши форматы файлов и все зависимые библиотеки. Он поддерживает почти все популярные дистрибутивы Linux, включая все версии SuSE и Fedora.

введите здесь описание изображения

person linuxbuild    schedule 15.01.2011

arrow_upward
2
arrow_downward

Это всего лишь личное мнение, но при распространении чего-либо в бинарной форме в Linux у вас есть несколько вариантов:

  1. Создайте гамму .debs и .rpms для каждого существующего дистрибутива с номинальным пакетом «.tar.gz, полный двоичных файлов» для всего, что вы пропустили. Первая часть идеальна, но громоздка. Последняя часть приведет вас к пунктам 2 и 3.

  2. Сделайте, как некоторые предлагают, и найдите самый старый дистрибутив, который вы можете найти и собрать там. Мое личное мнение, что это своего рода нелепая идея. См. пункт 3.

  3. Распространяйте двоичные файлы и статически связывайте везде, где это возможно. Особенно для libstdС++, что, по-видимому, является вашей проблемой. По-видимому, существует очень много несовместимых версий libstdc++, что делает его совместимость кошмаром. Если вы не можете связать статически, вы также можете поместить файлы *.so рядом с вашим двоичным файлом и использовать такие вещи, как LD_PRELOAD или LD_LIBRARY_PATH, чтобы они связывались предпочтительно во время выполнения. Обратите внимание, что если вы выберете этот путь, вам, возможно, придется соблюдать LGPL и т. д., поскольку теперь вы распространяете работу других людей вместе со своим проектом.

Конечно, в Linux всегда предпочтительнее распространять ваш проект в виде исходного кода. :-)

person asveikau    schedule 15.01.2011

arrow_upward
1
arrow_downward

Если сообщение представляет собой нераспознанный формат файла, то проблема, скорее всего, связана с упомянутой elmarco в комментарии, а именно с другой архитектурой. Возможно (я не уверен) это несоответствие версии динамического компоновщика, но это будет означать, что файл .so был создан с помощью древнего динамического компоновщика. Я не верю, что это может быть вызвано какой-либо несовместимостью в libc - они могут вызвать сбои связи и проблемы во время выполнения (последние очень редко), но не это.

person Robert Obryk    schedule 20.11.2009

arrow_upward
0
arrow_downward

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

person user183135    schedule 20.11.2009