Решение проблемы с ошибкой «bash: не удаётся запустить бинарный файл: Ошибка формата выполняемого файла»
В операционной системе Linux при запуске скаченного файла, либо при запуске самостоятельно скомпилированного файла вы можете столкнуться с ошибкой:
Если у вас англоязычная локаль, то ошибка будет примерно такой:
Причинами данной ошибки могут быть:
Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту 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:
Заключение
Итак, ошибка формата выполняемого файла с невозможностью запустить бинарный файл возникает из-за несоответствия программы операционной системе или архитектуре процессора. Эта проблема не должна возникать, если вы установили программу из исходных репозиториев (кроме случаев неправильной настройки источников репозитория). При возникновении этой проблемы поищите файл, подходящий для вашей архитектуры или скомпилируйте файл из исходных кодов под архитектуру вашей операционной системы.
Решение проблемы с ошибкой «bash: не удаётся запустить бинарный файл: Ошибка формата выполняемого файла»
В операционной системе Linux при запуске скаченного файла, либо при запуске самостоятельно скомпилированного файла вы можете столкнуться с ошибкой:
Если у вас англоязычная локаль, то ошибка будет примерно такой:
Причинами данной ошибки могут быть:
Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту 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:
Заключение
Итак, ошибка формата выполняемого файла с невозможностью запустить бинарный файл возникает из-за несоответствия программы операционной системе или архитектуре процессора. Эта проблема не должна возникать, если вы установили программу из исходных репозиториев (кроме случаев неправильной настройки источников репозитория). При возникновении этой проблемы поищите файл, подходящий для вашей архитектуры или скомпилируйте файл из исходных кодов под архитектуру вашей операционной системы.
Я пытаюсь запустить программу, но ошибка происходит так:
Результатом 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-разрядной версии, он работал без проблем.
qemu затем выполнит эмуляцию syscall при запуске исполняемого файла. Это работает для большинства двоичных файлов ARM, но есть некоторые, которые могут работать неправильно.
Такая ошибка может возникнуть, если выполняются все следующие условия:
Если java в системе установлено более одного, это может произойти и не будет установлено по умолчанию. На Ubuntu14.04 LTS я мог решить ее, выполнив следующее и выбрав java нужное.
Это также может произойти, если двоичный файл использует реализацию libc, которая не является libc, например, musl. В эти дни эта конкретная проблема, скорее всего, встречается при попытке запуска двоичного файла с libc в контейнере Docker с изображением, основанным на alpine. Ничто не может быть сделано с самим двоичным файлом для поддержки обеих сред, потому что реализация libc всегда должна быть статически связана, то есть встроена непосредственно в двоичный файл, по причинам.
Ошибка запуска java
При попытке установить и/или обновить java выдается
Пытаешься запустить 64 битный JDK на 32 битном дистрибутиве?
Сообщение об ошибке самообъясняющееся, хотя непонятно, как вы смогли установить это Java. Удалить и переустановить, если нужна эта версия. Если ставили не из хранилища, а загрузили дистрибутив, то его списать заново на случай если его архив дефектный.
миллиардный раз объясняю. Пакеты java в дистрибутивах создают обычно шизики.
способ установки человека, котоырй не хочет потом бегать с голой жопой:
1) Качаем JDK с официального сайта. JDK, а не JRE! Распаковываем в папочку.
3) Добавляем export PATH=$JAVA_HOME/bin:$PATH
Зачем заниматься этим рукоблудием, когда есть официальный rpm-пакет?
JDK 8 же от Оракла будет в EOL для незаплативших очень очень скоро. JDK 11 еще даже не зарелизилось. Бета-версии 9 и 10 не предлагать. Какой из сайтов теперь официальным для JDK 8 (такой себе жабааналог Python 2.7) будет?
Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.
потому что описанное выше решение работает в 146% случаев
146 лет в арче ставлю из репы, все работает на ура.
именно так ставится оракловая java из ppa на дебиан-бубунту.
Судя по всему у тс проблемы как раз от того что он руками её ставил. Ну или рач какой-нить.
для легаси проектов, которые на JDK11 не запускаются, можешь использовать сборки от Азула, они обещали патчить беслпатно: https://www.azul.com/downloads/zulu/
Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.
Я лично остаюсь на восьмёрке и просто не буду обновляться, если не найдётся серьёзный вендор. Мне нужна 32-битная джава, которая нормально работает на XP. Про обновляться раз в полгода это вообще несерьёзно.
Таких людей про «обновляться несерьезно» оказалось исчезающе малое количество. Проще на них забить.
мм.. как все сложно. У меня в федоре JDK «просто работает» из коробки и мне даже не приходило в голову, что с ней бывает нужно как-то изощряться
Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.
Вроде October 2020 для jdk8 это не очень уж и долго, всего на полтора года дольше чем Oracle Java 8. Но внимание, тынц на предыдущую версию этой страницы:
Рекомендую обновляться раз в полгода.
Ах-ха-ха, ну конечно, все жабаынтырпрайзы сразу запишутся в бета-тестеры. LTS версии есть для юзеров же. А у jdk8 есть все шансы стать «супер-LTS» по примеру Python 2.7.
Вопросов больше не имею, написал бы сразу что сектант. В приличных местах за попытку протолкнуть в продакшен «кустарные контейнеры» (не путать с кубернетесами и прочими облаками, которыми специально выделенные девопсы рулят), могут профнепригодность прописать.
И это будет финальный гвоздь в крышку гроба Java. Печально, что Партия решила воссоздать в экосистеме такой же отвратный бардак, который сегодня царит, например, в Web-разработке.
Я лично остаюсь на восьмёрке и просто не буду обновляться
+1, как и руководства многих разумных ынтерпрайзных предприятий.
Про обновляться раз в полгода это вообще несерьёзно.
+2, если Партия будет заставлять обновляться каждые полгода на новую мажорную версию, то обновления будут происходить «на другой язык».
Мне нужна 32-битная джава, которая нормально работает на XP
Рекомендую мониторить следующие места на предмет jdk8-32-bit-оффтоп:
в отличие от бардака в веб-разработке, тут релизы релизят настоящие волшебники, и каких-то особых проблем с обновлениями быть не должно.
никаких left-pad, если ты об этом
На компьютере, с которого сейчас пишу, JDK 10.0.1 apt-get’ом нормально установился.
А вот Eclipse Photon я ставил в /opt ручками.
На работе в «продакшене» JRE и JDK ставлю только ручками.
PS. Еще ANT_HOME и M2_HOME тоже желательно указать.
В enterpriZe никакого «бардака» нет.
А есть Oracle и IBM.
Это ты сейчас на каком языке пишешь?
А есть какие-нибудь доки или мини-книжки/статьи про новые «фишки» в 9-10-11 java для тех, кто на ней редко пишет? Так сказать, понять, что нового по сравнению с 8-кой.
кроме бешеного количества статей, которые и без меня насоветуют, подскажу еще один способ, который полезен для формального доказательства начальству
Видно, что в 9 действительно много изменений, но почти все они касаются не прикладных разработчиков, а разработчиков фреймворков. То есть, прикладник обычно может просто обновить фреймворки до последней версии и жить как будто ничего не случилось. Ну да, с обновлением фреймворков придется повозиться, если запустил кодовую базу
А в 10 и 11 там по сути, всякая минорщина. Не факт что на ЛОРе бы про такое разрешили писать мини-новость.
Нет в этом ничего жуткого, необычного. Чего-то такого, что разработчики на почти любых других технологиях не видели бы при самых обычных обновлениях
Как обычно, истерят в основном белки-истерички
Ну, а как вообще, сообщество/опенсорс, пишет под 9-10-11 или всё медленно движется?
Если ты об backward compatibility, то все основные вещи давным-давно совместимы вплоть до 11. Специально собиралась статистика, были какие-то тэги в твиттере, но это уже не актуально. Всё просто работает. За исключением вещей вроде JavaEE и Nashorn.js, которых просто выбросили из JDK на мороз.
Основной дизастер был за пару месяцев до и после выхода 9 в прошлом году. После этого уже не было ченжей, чтобы что-то там поломалось. Ченжи вроде добавления Shenandoah GC приносят новые крутые фичи и не способны что-то поломать на уровне пользовательского API
Кишори Шаран «Java 9. Полный обзор нововведений» для быстрого ознакомления и миграции. ДМК Пресс, 2018. ISBN 978-5-97060-575-2
Как запустить бинарный файл в Linux
8 ответов
и если произойдет сбой, скажем, из-за разрешений, вы можете попробовать это перед выполнением
Надеюсь, это поможет
Возможно, вы скомпилировали бинарный файл с несовместимыми параметрами архитектуры на хосте сборки и хосте выполнения. Можете ли вы взглянуть на включенные настройки цели через
на вашем хосте сборки? В частности, переменная COLLECT_GCC_OPTIONS может дать вам ценную отладочную информацию. Затем взгляните на возможности процессора на хосте выполнения через
Если это не помогает, предоставьте выходные данные ldd commonKT как на хосте сборки, так и на хосте выполнения.
Я только что скомпилировал файл из источника C и установил его для запуска с помощью chmod. От gcc не было ни предупреждений, ни сообщений об ошибках.
Теперь я попытался создать объектный файл, вот так:
С другой стороны, таким образом, выходные данные команды file идентичны вашей:
Тогда как, если я правильно скомпилирую, его вывод будет намного длиннее.
Я говорю следующее: я подозреваю, что это как-то связано с тем, как вы компилируете и связываете свой код. Может быть, вы можете пролить свет на то, как вы это делаете?
Единственный способ, который подходит мне ):
Затем запустите его, написав
Если вы получили ошибку разрешения, вам может потребоваться запустить приложение с привилегиями root:
Если это не опечатка, как указывалось ранее, это может быть неправильными параметрами компилятора, такими как компиляция 64-битной под 32-битной. Это не должен быть набор инструментов.
полный путь для двоичного файла. Например: /home /vitaliy2034 /имя_бинального_файла. Или же используйте директиву «./+binary_file_name». ‘./’ в системе unix возвращает полный путь к каталогу, в котором вы открываете терминал (оболочку). Я надеюсь, что это помогает. Извините за мой английский язык)