Вопросы Теги

Создание и упаковка портативной программы ffmpeg Linux ('GLIBC_2.27' не найден) [дубликат]

Попробуйте следующее: 

echo exec('ping -n 1 -w 1 72.10.169.28');
24
задан rubik 2 March 2016 в 18:01
поделиться

3 ответа

Я не знаю, что такое Yesod, но я знаю точно , что означает каждая из ваших других ошибок.

Сначала вы должны not попробовать для связывания статически. Предупреждение, которое вы получаете, совершенно правильно: если вы ставите статическую ссылку и используете одну из подпрограмм, для которой вы получаете предупреждение, тогда вы должны организовать запуск в системе с точно той же самой версии libc .so.6 как тот, который вы использовали во время сборки.

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

Ваши другие (статические) ошибки ссылок вызваны отсутствием libopenssl.a во время соединения.

Но давайте предположим, что вы собираетесь идти по «нормальному» маршруту и ​​используйте динамическую привязку.

Для динамической компоновки Linux (и большинство других UNIX) поддерживает обратную совместимость: старый двоичный файл продолжает работать на более новых системах. Но они не поддерживают форвардную совместимость (двоичный код, построенный на более новой системе, обычно будет , а не работать на более старом языке.)

Но это то, что вы пытаетесь сделать: вы построенный на системе с glibc-2.14 (или новее), и вы работаете в системе с glibc-2.13 (или старше).

Другое, что вам нужно знать, это то, что glibc состоит из некоторых 200+, которые должны соответствовать точно . Двумя ключевыми двоичными файлами являются /lib/ld-linux.so и /lib/libc.so.6 (но их еще много: libpthread.so.0, libnsl.so.1 и т. Д. И т. Д.). Если некоторые из этих двоичных файлов поступают из разных версий glibc, вы обычно получаете сбой. И это именно то, что вы получили, когда вы попытались поместить свой glibc-2.14 libc.so.6 на LD_LIBRARY_PATH - он больше не соответствует системе /lib/ld-linux.

Итак, каковы решения? Существует несколько возможностей (с большим трудом):

  1. Вы можете скопировать ld-2.14.so (цель символа /lib/ld-linux) в целевую систему и явно вызвать его: 
    /path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
    Это вообще работает, но может запутать приложение, которое смотрит на argv[0], и ломается для приложений, которые повторно запускают себя.
  2. Вы можете использовать более старую систему.
  3. Вы можете использовать appgcc (этот параметр исчез, см. этот для описания того, чем он был раньше).
  4. Вы можете настроить среду chroot, соответствующую целевой системе, и построить внутри нее chroot.
  5. Вы можете создать себе кросс-компилятор Linux-to-oldLinux
51
ответ дан Employed Russian 20 August 2018 в 07:57
поделиться
  • 1
    Хорошо, поэтому я скопировал ld-2.14.so в мою сборку heroku вместе с libc.so.6 и libgmp.so.10 из моей системы и сменил команду запуска heroku на указанную вами. Приложение теперь терпит крах (по крайней мере, нет выхода из аварии в журналах heroku, состояние просто меняется от начала до разбитого). Если я запустил heroku run ./lib/ld-linux-x86-64.so.2 --list /path/to/executable, все библиотечные зависимости заполнены, , но большинство из них удовлетворяются системными библиотеками. Нужно ли мне копировать библиотеки all с помощью приложения из моей системы? – asm 28 December 2011 в 19:46
  • 2
    Вам не нужно строить статически; из того, что я понимаю, даже без -static и друзей, GHC свяжет GHC RTS с вашим исполняемым файлом (который вам нужен, поскольку Heroku, вероятно, не имеет среды исполнения GHC, доступной как lib), если вы явно не компилируете с помощью -dynamic. По умолчанию библиотеки , используемые RTS , нравятся динамически, что было бы разумно для вашего дела. См. Также: stackoverflow.com/questions/699908/… – Dan Burton 28 December 2011 в 23:30
  • 3
    Я нашел это с момента публикации. Похоже, что основной проблемой является тот факт, что мой libc новее, чем то, что на хостах Heroku, как предлагал Employed Russian. – asm 29 December 2011 в 00:23
  • 4
    @domen Я обновил ответ. – Employed Russian 20 February 2013 в 20:10
  • 5
    Я думаю, что это утверждение очень неточно: «Вопреки распространенному мнению, статическое связывание создает меньше, не более переносимых исполняемых файлов в Linux». Как вы знаете, Linux никогда не нарушает API-совместимость. Вы имели в виду сказать Glibc вместо Linux? Я действительно не понимаю, как это имеет отношение к собственно Linux. – Janus Troelsen 17 March 2015 в 16:06

У меня возникли аналогичные проблемы с запуском Heroku (который использует glibc-2.11), где у меня было приложение, которое требовало glibc-2.14, но у меня не было доступа к источнику и он не мог его перестроить. Я пробовал много вещей и ничего не работал.

Мое обходное решение состояло в том, чтобы запустить службу на Amazon Elastic Beanstalk и просто предоставить интерфейс API.

0
ответ дан idrinkpabst 20 August 2018 в 07:57
поделиться

У вас есть несколько проблем.

Вы не должны создавать производственные двоичные файлы на граничных распределениях кровотечений. Библиотеки на производственной системе не будут переадресованы.

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

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

Но в целом - уменьшите распределение .

5
ответ дан user239558 20 August 2018 в 07:57
поделиться
  • 1
    Учитывая, что герою по-прежнему находится в этой старой версии, что имеет смысл с намерением обеспечить стабильную платформу, можно вызвать glibcs ​​& gt; 2.11 едва ли «кровоточащий край». Тем не менее, ваш ответ мог бы иметь смысл в декабре 2011 года. – radiospiel 20 August 2013 в 11:45
Другие вопросы по тегам:

Похожие вопросы: