Execvp ошибка формата выполняемого файла

Перейти к содержимому

Неизвестная ошибка 100
execvp: Ошибка формата выполняемого файла
Отправьте сообщение об ошибке на https://bugs.kde.org

[Desktop Entry]
...
Exec=sqldeveloper
...

$ which sqldeveloper
/usr/local/bin/sqldeveloper

$ file "$(which sqldeveloper)"
/usr/local/bin/sqldeveloper: ASCII text

$ head -2 "$(which sqldeveloper)"
/opt/sqldeveloper/sqldeveloper.sh

$ cat /opt/sqldeveloper/sqldeveloper.sh
#!/bin/bash
cd "`dirname $0`"/sqldeveloper/bin && bash sqldeveloper $*

$ file "$(which sqldeveloper)"
/usr/local/bin/sqldeveloper: Bourne-Again shell script, ASCII text executable

Как я могу устранить ошибку «не удается выполнить двоичный файл»?

Когда я захожу через SSH, я вижу только это .

Я ничего не мог сделать здесь. Такие команды, как halt , poweroff , reboot , вернут command not found .

Как я могу это исправить? Я использую Debian Squeeze Linux

7 ответов 7

Обычно это сообщение об ошибке означает, что Linux не распознает файл как сценарий оболочки или как исполняемый файл.

Обычно причиной является запуск исполняемого файла в неправильной архитектуре — если вы попытаетесь запустить исполняемые файлы x86 на процессоре ARM, появится это сообщение.

Возможно, файл /usr/bin/id перезаписан?

Попробуйте запустить его, используя ./executablefilename вместо использования sh executetablefilename. В конце концов, это не скрипт оболочки.

Проблема заключается в запуске двоичного файла для другой архитектуры процессора. Вы можете использовать objdump (из binutils) для проверки архитектуры двоичных файлов. Вы можете использовать uname для проверки архитектуры машины.

Например, я столкнулся с этой ошибкой «невозможно выполнить двоичный файл» при установке FF.Communicator — плагина Firefox для Chrome (поэтому я могу запускать страницы, которые используют Java-апплеты).

objdump показывает, что двоичный файл является 64-битным elf64-x86-64

uname показывает, что моя машина 32-битная i686

$./FF.Communicator bash:./FF.Communicator: невозможно выполнить двоичный файл $ uname -mpio i686 i686 i386 GNU/Linux $ objdump -a./FF.Communicator./FF.Communicator: формат файла elf64-x86-64./FF.Communicator

objdump на работающем бинарнике на моей машине показывает, что это 32-битный elf32-i386

$ objdump -a /bin /ls /bin /ls: формат файла elf32-i386

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

Для пользователей Mac OSX вы можете узнать информацию об архитектуре определенного файла, используя команду «file»:

Источник

execvp: Ошибка формата выполняемого файла

1) sudo chmod +x ./joxi.run
2) ./joxi.run

3) (Запускается только до перезагрузки ПК и только через root)

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-root’

void Autorization::listen() *2 62000

bool Setting::connectDatabase() QThread(0x5617d599a3a0)

void SqlWorker::connectToDatabase(QString) «/root/.joxi/setting»

После каждой перезагрузки ПК, Joxi перестаёт запускаться и заново надо его переустанавливать.

Скрипт joxi.sh выдаёт ошибку «execvp: Ошибка формата выполняемого файла«.

/Загрузки$ sudo chmod +x ./joxi.run

[sudo] пароль для alexandr:

/Загрузки$ sudo su

Creating directory joxi

Verifying archive integrity. 100% MD5 checksums are OK. All good.

Uncompressing Joxi — best screenshot capture 100%

-rwx—— 1 alexandr alexandr 351 июн 5 22:32 install.sh

-rwx—— 1 alexandr alexandr 4305176 июн 5 22:32 joxi

-rwx—— 1 alexandr alexandr 86 июн 5 22:32 joxi.desktop

-rwx—— 1 alexandr alexandr 50 июн 5 22:32 joxi.sh

/joxi$ ./joxi
qt.qpa.plugin: Could not load the Qt platform plugin «xcb» in «» even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

/joxi$ sudo ./joxi
[sudo] пароль для alexandr:
qt.qpa.plugin: Could not load the Qt platform plugin «xcb» in «» even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

Operating System: KDE neon 5.18
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2
Kernel Version: 5.3.0-53-generic
OS Type: 64-bit

Источник

bash: ./program: невозможно выполнить двоичный файл: ошибка формата Exec

Я пытаюсь запустить программу, но ошибка происходит следующим образом:

Результатом программы file program был:

Как я могу исправить эту ошибку?

Я использую Ubuntu 14.04.2 (amd64) с VMware. Я также пытался использовать Ubuntu i386, но результат был таким же.

6 ответов

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

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

Получите версию исполняемого файла x86-64 (любым способом, если вы не можете получить версию исполняемого файла x86-64, но вы можете получить его исходный код, вы можете попробовать перекомпилировать его на виртуальной машине);

Установите сервер Ubuntu для ARM вместо Ubuntu 14.04.2 (amd64). Для этого требуется либо физическая машина, работающая в архитектуре ARM, либо программное обеспечение для виртуализации, которое может имитировать ее.

Это также может произойти, если вы попытаетесь запустить исполняемый файл x86-64 на 32-разрядной платформе.

В одном конкретном экземпляре я загрузил код Visual Studio и попытался запустить его на моей установке Ubuntu, но я не понял, что в этой виртуальной машине был установлен 32-разрядный Ubuntu. Я получил эту ошибку, но после загрузки 32-разрядной версии она запускалась без проблем.

Часто можно запустить исполняемый образ ARM в системе amd64, если вы установите binfmt-support , qemu и qemu-user-static пакеты:

qemu будет выполнять эмуляцию syscall при запуске исполняемого файла. Это работает для большинства двоичных файлов ARM, но есть некоторые из них, которые могут работать некорректно.

Такая ошибка может возникнуть, если выполняются все следующие условия:

• Исполняемый файл не является файлом, а ссылкой
• Вы запустите его внутри VM
• Файл находится в общей папке
• Ваш хост — это Windows.

Если у вас есть этот файл, скажем, в архиве — попробуйте распаковать его внутри виртуальной машины, в какой-то каталог внутри виртуального диска, а не на папку, привязанную к вашему жесткому диску хост-компьютера, например /myNewDir/

Если в системе установлено более одного java , это может произойти и не будет установлено как значение по умолчанию. В Ubuntu14.04 LTS я мог бы решить эту проблему, выполнив следующие и выбрав java , который мне нужен.

Я выбираю 2 и устанавливаю openjdk-8 по умолчанию. Который не отображал ошибку Exec format error .

Вы должны скомпилировать свой файл с использованием соответствующей архитектуры процессора (например, x86) и скопировать файл .exe на вашу Linux-машину. Затем вы можете установить моно на свою Linux-машину и выпустить следующую команду:

Источник

bash: ./program: невозможно выполнить двоичный файл: ошибка формата Exec

Я пытаюсь запустить программу, но ошибка происходит так:

Результатом file program было:

Как я могу исправить эту ошибку?

Я использую Ubuntu 14.04.2 (amd64) с VMware. Я тоже пробовал с Ubuntu i386, но результат был таким же.

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

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

Получить версию исполняемого файла x86-64 (любым способом; если вам не удается получить версию исполняемого файла x86-64, но вы можете получить его исходный код, вы можете попытаться перекомпилировать его на виртуальной машине );

Установите Ubuntu Server for ARM вместо Ubuntu 14.04.2 (amd64). Для этого требуется либо физическая машина, работающая на архитектуре ARM, либо программное обеспечение для виртуализации, которое может эмулировать ее.

Это также может произойти, если вы попытаетесь запустить исполняемый файл x86-64 на 32-разрядной платформе.

В одном конкретном случае я скачал код Visual Studio и попытался запустить его на своей установке Ubuntu, но я не понял, что я установил 32-битную Ubuntu в эту виртуальную машину. Я получил эту ошибку, но после загрузки 32-разрядной версии, он работал без проблем.

Часто можно запустить исполняемый образ ARM в системе amd64, если вы установите пакеты binfmt-support , qemu и qemu-user-static :

qemu затем выполнит эмуляцию syscall при запуске исполняемого файла. Это работает для большинства двоичных файлов ARM, но есть некоторые, которые могут работать неправильно.

Такая ошибка может возникнуть, если выполняются все следующие условия:

• Исполняемый файл — это не файл, а ссылка
• Вы запускаете запустить его внутри ВМ
• Файл находится в общей папке
• Ваш хост — Windows.

Если вы получили этот файл, скажем, в архиве — попробуйте распаковать его внутри виртуальной машины, в какой-то каталог внутри виртуального диска, а не в папку, сопоставленную, например, с жестким диском хост-машины. /myNewDir/

Вы должны скомпилировать свой файл, используя соответствующую архитектуру ЦП (например, x86), и скопировать файл .exe на свой компьютер с Linux. Затем вы можете установить mono на вашем Linux-компьютере и выполнить следующую команду:

Если java в системе установлено более одного, это может произойти и не будет установлено по умолчанию. На Ubuntu14.04 LTS я мог решить ее, выполнив следующее и выбрав java нужное.

Я выбираю 2 и устанавливаю openjdk-8 по умолчанию. Который не показал Exec format error .

Это также может произойти, если двоичный файл использует реализацию libc, которая не является libc, например, musl. В эти дни эта конкретная проблема, скорее всего, встречается при попытке запуска двоичного файла с libc в контейнере Docker с изображением, основанным на alpine. Ничто не может быть сделано с самим двоичным файлом для поддержки обеих сред, потому что реализация libc всегда должна быть статически связана, то есть встроена непосредственно в двоичный файл, по причинам.

Источник

Решение проблемы с ошибкой «bash: не удаётся запустить бинарный файл: Ошибка формата выполняемого файла»

В операционной системе Linux при запуске скаченного файла, либо при запуске самостоятельно скомпилированного файла вы можете столкнуться с ошибкой:

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

В самой ошибке вместо /путь/до/файла и ./program будет указан путь до файла программы, который вы хотите запустить.

Причинами данной ошибки могут быть:

• • попытка запустить 64-битный файл на 32-битной системе

• • файл скомпилирован для другой архитектуры (например, для ARM, а вы пытаетесь запустить его на ПК)

• • вы пытаетесь выполнить не исполнимый файл, а ссылку

Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту file, после которой укажите путь до файла:

Здесь мы видим, что файл предназначен для 64-битной системы, об этом говорит запись 64-bit, для процессора с архитектурой x86-64.

Ещё один пример:

Этот файл для 32-битных систем, для процессора с архитектурой ARM EABI4.

Если вы не знаете, какой битности ваша система, то выполните команду:

Для 64-битных систем будет выведено x86_64, а для 32-битных – x86.

О разрядности дистрибутивов Linux и о программ

На компьютер с 32-битным процессором вы можете установить только 32-битную операционную систему и в ней запускать только 32-битные программы.

На компьютер с 64-битным процессором вы можете установить как 64-битную ОС, так и 32-битный Linux. В случае, если вы установили 64-битный дистрибутив Linux, то в нём вы можете запускать и 64-битные программы и 32-битные. А если вы установили 32-битный дистрибутив, то в нём возможно запускать только 32-битные программы.

Итак, если у вас 32-битная система, а файл для 64-битной системы или даже для ARM архитектуры, то у вас следующие варианты:

• • скачать файл подходящей для вас битности и архитектуры

• • если вы самостоятельно компилировали файл из исходного кода, то заново скомпилируйте для процессора вашей архитектуры

Запуск ARM файлов в Linux

Часто можно запустить исполнимые образы ARM на amd64 системах если установить пакеты binfmt-support, qemu, и qemu-user-static:

Заключение

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

Источник

У нас есть две системы RHEL 6, в которых работают идентичные версии ядра и glibc (glibc – 2.12–1.90.el6_3.6). Согласно стандарту POSIX и справочным страницам Linux, если ядро определяет, что исполняемый файл не в исполняемом формате, таком как ELF, и у него нет шебанга (#!) line, функции execl , execlp , execle , execv , execvp и execvpe (но не execve) будут пытаться выполнить этот файл с помощью оболочки POSIX, которая в Linux называется /bin/sh .

Однако в одной из систем выполнение сценария оболочки, первая строка которого : использование функции execvp завершается ошибкой, в то время как на другой машине сценарий выполняется с использованием /bin/sh , как и ожидалось. В частности, мы используем эти тестовые программы; /tmp/test_script сделан исполняемым:

хс:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

extern char **environ;

int main () {
        char *argv[]   = { "/tmp/test_script", NULL };
        char *progname = argv[0];
        if (execvp(progname, argv) == -1) {
                perror("execvp");
                return -1;
        }
}

/ TMP / test_script:

:

echo "Test script called"
exit 0

Мы искали в исходной RPM установленную версию glibc, и она определенно реализует желаемое поведение (execvp — тривиальная оболочка вокруг execvpe):

POSIX /execvpe.c:

if (strchr(file, '/') != NULL)
    {
        /* Don't search when it contains a slash.  */
        __execve(file, argv, envp);

        if (errno == ENOEXEC)
            {
                /* Count the arguments.  */
                int argc = 0;
                while (argv[argc++])
                    ;
                size_t len = (argc + 1) * sizeof(char *);
                char **script_argv;
                void *ptr = NULL;
                if (__libc_use_alloca(len))
                    script_argv = alloca(len);
                else
                    script_argv = ptr = malloc(len);

                if (script_argv != NULL)
                    {
                        scripts_argv(file, argv, argc, script_argv);
                        __execve(script_argv[0], script_argv, envp);

                        free(ptr);
                    }
            }
    }
else
   ︙

Здесь scripts_argv — это простая функция, которая добавляет /bin/sh в список аргументов, а __execve идентична execve , доступному для пространства пользователя через glibc.

Кто-нибудь еще сталкивался с этой проблемой в Linux? Поведение корректно в любой другой системе, на которой я его пробовал.