исполняемый двоичный файл: файл не найден

Я знаю, что есть похожие вопросы, но я не нашел ни решения, ни этого точного случая. Двоичный файл был построен на Arch Linux с использованием его GCC 4.7. Пакет отлично работает в системе сборки. Команды ниже были выполнены на:

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP пт 27 июля 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

Данный файл находится здесь . Это 64-битный кросс-компилятор с 64-битной операционной системы Linux. Распаковка ~/дает один ~/mingw64каталог, который содержит все необходимое.

Когда я пытаюсь запустить ~/mingw64/x86_64-w64-mingw32/bin/asэто то, что я получаю:

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

Бег file ~/mingw64/x86_64-w64-mingw32/bin/asдает мне:

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

Бег ldd ~/mingw64/x86_64-w64-mingw32/bin/asдает мне:

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

Я действительно в растерянности. Буду признателен за любую оказанную помощь.

РЕДАКТИРОВАТЬ : Еще несколько деталей: Система сборки - Arch Linux (в настоящее время glibc 2.16). Вывод ls -l:

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

Вывод objdump -p:

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

Выход ldd -vна Ubuntu 12.04:

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Другие протестированные ОС - это Fedora 17 (glibc 2.15) и Ubuntu 12.04 (eglibc 2.15). Требования к версии zlib и glibc выполнены.

— rubenvb
источник

это просто опечатка или вы действительно пытаетесь запустить '~ / mingw64 / x86_64-w64-mingw32 / as' ... в ней отсутствует папка 'bin'.

— тройной

Тип @tripledes и исправлено.

— rubenvb

странно, только что попытался скачать, распаковать под моим ~ и я получаю ожидаемый результат. Не могли бы вы предоставить ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as?

— тройной

Может ли это быть несоответствие версии libc? Попробуйте запустить «objdump -p <path / to / as>» и проверить раздел «Ссылки на версии». Может показаться, что это зависит от GLIBC_2.14, который можно считать довольно новым. Какая у вас версия системы? "readelf -a <path / to / as> | less" и grep для GLIBC, вы увидите, что он использует memcpy из 2.14. Я не знаю, почему версия будет так сильно различаться между различными вызовами библиотеки.

— svenx

Ответы:

Если я запускаю ldd -v asсвою систему, я получаю:

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

Так что да, похоже, что эти двоичные файлы ищут GLIBC_2.14символ, который, по-видимому, вам не хватает в вашей системе. Как указывал svenx, похоже, что он ищет memcpy@@GLIBC_2.14символ. Еще немного информации о том, почему memcpyбыла дана новая версия, описано в этом отчете об ошибках .

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

Прочитав ваше обновление : вы правы, это не было вашей проблемой. Но я думаю, что нашел: ваш бинарный файл запрашивает интерпретатор /lib/ld-linux-x86-64.so.2, которого нет в системах Ubuntu 12.04:

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

Хотя я lddзнал, что найти его /lib64вместо этого, я предполагаю, что ядро не знает об этом, когда пытается запустить двоичный файл, и не может найти требуемый интерпретатор файла. Вы можете попробовать запустить его через интерпретатор вручную:

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

Я не уверен на 100%, что это работает правильно - в моей системе gccтакой способ дает ошибку сегментации. Но это как минимум другая проблема.

— Джим Пэрис
источник

Это было бы хорошо, если бы это было так. Смотрите обновление:(

— rubenvb

Я обновил свой ответ.

— Джим Пэрис

Вау окей Этот вид отстой. Я не могу придумать достойного способа обойти эту проблему (и продолжать строить на Арче). Есть ли у вас блестящие идеи?

— rubenvb

На самом деле, нет. Arch просто глуп: стандарт Heirarchy файловой системы четко говорит, что библиотеки должны быть /lib64на amd64, и, очевидно, Arch вручную исправляет свои исходные коды gcc, чтобы изменить это, гарантируя тем самым несовместимость с любым другим дистрибутивом Linux. См. Комментарии к этому сообщению об ошибке для их причудливых рассуждений. Для меня это было бы явным предупреждением, чтобы держаться подальше от Arch Linux.

— Джим Пэрис

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

— Джим Пэрис

Ваша проблема - вариант получения сообщения «Не найдено» при запуске 32-разрядного двоичного файла в 64-разрядной системе : у вас есть исполняемый файл, в котором упоминается динамический загрузчик, которого там нет.

В вашем случае динамический загрузчик /lib/ld-linux-x86-64.so.2существует, но в другом месте /lib64/ld-linux-x86-64.so.2. Самый простой способ заставить ваши программы работать - создать символическую ссылку:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/

— Жиль "ТАК - перестань быть злым"
источник

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

— rubenvb