Не удается запустить бинарный файл ошибка формата выполняемого файла linux

Запуск исполняемых файлов.

Сразу укажу, что я полнейший нуб. Учусь пользоваться линуксом. Сейчас стоит fedora 22. Не запускаются скомпилированные исполняемые файлы. Компилирую СИшные файлики через ком строку. «gcc -c file.c -o file.o» и «gcc file.o -o file». После этих действий выдает ошибку при запуске через sh «не могу запустить бинарный файл.» Не хочет запускать ни file.o, ни file. Переустанавливал bash и gcc через ком строку с помощью dnf reinstall, не помогло. Мне интересен любой способ решения этой проблемы, который я буду способен в кратчайшие сроки освоить.

Предлагаешь нам самим догадаться, как именно ты запускаешь этот файл?

Дай право на выполнение:

[root@localhost программы]# gcc -c pr1.c -o pr1.o [root@localhost программы]# gcc pr1.o -o pr1 [root@localhost программы]# sh pr1 pr1: pr1: не могу запустить бинарный файл [root@localhost программы]# chmod +x pr1 [root@localhost программы]# sh pr1 pr1: pr1: не могу запустить бинарный файл [root@localhost программы]# ls pr1 pr1.c pr1.o адрес [root@localhost программы]# chmod a=x pr1.o [root@localhost программы]# pr1.o bash: pr1.o: команда не найдена. ^C [root@localhost программы]# sh pr1.o pr1.o: pr1.o: не могу запустить бинарный файл [root@localhost программы]# ./pr1.o bash: ./pr1.o: cannot execute binary file: Ошибка формата выполняемого файла [root@localhost программы]# ./pr1 указатель не определен

[root@localhost программы]# chmod +x pr1.o

[root@localhost программы]# ./pr1.o

bash: ./pr1.o: cannot execute binary file: Ошибка формата выполняемого файла

Ну фиг его знает. Выложи что ты там собираешь.

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

Источник

Как запустить бинарный файл в Linux

У меня есть файл с именем commanKT и я хочу запустить его в терминале Linux. Может кто-то помочь, дав команду запустить этот файл? Я пытался ./commonRT , но я получаю сообщение об ошибке:

8 ответов

Чтобы выполнить двоичный файл или .run-файл в Linux из оболочки, используйте косую черту друга

и если произойдет сбой, скажем, из-за разрешений, вы можете попробовать это перед выполнением

Надеюсь, это поможет

🙂 Если вы не опечатка, почему вы используете ./commonRT вместо ./commonKT ??

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

на вашем хосте сборки? В частности, переменная COLLECT_GCC_OPTIONS может дать вам ценную отладочную информацию. Затем взгляните на возможности процессора на хосте выполнения через

Обратите внимание на несоответствия, такие как -msse4.2 [enabled] на хосте сборки, но отсутствует sse4_2 флаг в возможностях процессора.

Если это не помогает, предоставьте выходные данные ldd commonKT как на хосте сборки, так и на хосте выполнения.

Это ответ на @craq:

Я только что скомпилировал файл из источника C и установил его для запуска с помощью chmod. От gcc не было ни предупреждений, ни сообщений об ошибках.

Я немного удивлен, что вам пришлось «установить его на исполняемый файл» — мой gcc всегда устанавливает сам флаг исполняемого файла , Это говорит о том, что gcc не ожидал, что это будет конечный исполняемый файл, или что он не ожидал, что он будет исполняемым в этой системе.

Теперь я попытался создать объектный файл, вот так:

( hello.c — типичная программа «Hello World».) Но мое сообщение об ошибке немного отличается:

С другой стороны, таким образом, выходные данные команды file идентичны вашей:

Тогда как, если я правильно скомпилирую, его вывод будет намного длиннее.

Я говорю следующее: я подозреваю, что это как-то связано с тем, как вы компилируете и связываете свой код. Может быть, вы можете пролить свет на то, как вы это делаете?

Единственный способ, который подходит мне ):

Затем запустите его, написав

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

опция компиляции -c делает компиляцию только компиляцией и сборкой, но без ссылки.

Если это не опечатка, как указывалось ранее, это может быть неправильными параметрами компилятора, такими как компиляция 64-битной под 32-битной. Это не должен быть набор инструментов.

полный путь для двоичного файла. Например: /home /vitaliy2034 /имя_бинального_файла. Или же используйте директиву «./+binary_file_name». ‘./’ в системе unix возвращает полный путь к каталогу, в котором вы открываете терминал (оболочку). Я надеюсь, что это помогает. Извините за мой английский язык)

Источник

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

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

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

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

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

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

Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту 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: ./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 всегда должна быть статически связана, то есть встроена непосредственно в двоичный файл, по причинам.

Источник

Ошибка запуска java

При попытке установить и/или обновить java выдается

Пытаешься запустить 64 битный JDK на 32 битном дистрибутиве?

Сообщение об ошибке самообъясняющееся, хотя непонятно, как вы смогли установить это Java. Удалить и переустановить, если нужна эта версия. Если ставили не из хранилища, а загрузили дистрибутив, то его списать заново на случай если его архив дефектный.

Ну и выложи еще

миллиардный раз объясняю. Пакеты java в дистрибутивах создают обычно шизики.

способ установки человека, котоырй не хочет потом бегать с голой жопой:

1) Качаем JDK с официального сайта. JDK, а не JRE! Распаковываем в папочку.

2) Прописываем переменную export $JAVA_HOME=, указывающую на то место, куда распаковали.

3) Добавляем export PATH=$JAVA_HOME/bin:$PATH

Если джава планируется запускаться от пользователя — то распаковывать в его домашнюю папку и прописывать экспорты в

Если джава планируется запускаться системно — то распаковываем куда-нибудь в корень (например, в /opt/jdk), переменные прописываем в /etc/profile.

Зачем заниматься этим рукоблудием, когда есть официальный rpm-пакет?

потому что описанное выше решение работает в 146% случаев, а практически любое другое (включая «официальный» rpm-пакет) — нет

JDK 8 же от Оракла будет в EOL для незаплативших очень очень скоро. JDK 11 еще даже не зарелизилось. Бета-версии 9 и 10 не предлагать. Какой из сайтов теперь официальным для JDK 8 (такой себе жабааналог Python 2.7) будет?

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

потому что описанное выше решение работает в 146% случаев

146 лет в арче ставлю из репы, все работает на ура.

Arch Linux не предназначен для работы, поэтому эта делёжка опытом не актуальна. Но я как-то был на компьютерных курсах, где изучалась одна программа на Java. Преподаватель был слабый — знал ненамного больше, чем рассказывал. и излагал так, что я ничего бы не понял, если бы и без того это не знал. Неудивительно, что он поставил на учебные компьютеры Arch Linux, и совсем не удивительно, что программа зависала. Я проверил её в Debian и Fedora — как я и ожидал, работала нормально. JDK может понадобиться до двух версий- 10 и (для старых программ) 8. Сам он бывает двух видов — OpenJDK (этот входит в хранилища) и Oracle JDK (этот списывается с сайта Oracle). Иногда энтузиасты предоставляют свои PPA архивы со стандартным JDK.Но это не основной способ установки.В общем, стандартный JDK от Oracle лучше тем, что больше проверен, и производители некоторых важных программ тестируют их на совместимость с ним. Но может устроить и OpenJDK. У автора вопроса проблема в том, что он поставил JDK неправильно. Из его описания не видно, как. Может, архив битый или он запускает 64 битный JDK в 32 битной ОС. В общем, убрать этот ущербный JDK и установить заново, ознакомившись с инструкцией, как это делать.

именно так ставится оракловая java из ppa на дебиан-бубунту.

Судя по всему у тс проблемы как раз от того что он руками её ставил. Ну или рач какой-нить.

новые сборки джавы будут раз в полгода. Рекомендую обновляться раз в полгода. Это новая политика Партии, от нее никуда не деться. Все кто будут пытаться делать вид, что ничего не произошло — будут жутко мучиться, и решения этому нет никакого. Комьюнити _специально_ позаботилось, чтобы этому не было никакого решения.

для легаси проектов, которые на JDK11 не запускаются, можешь использовать сборки от Азула, они обещали патчить беслпатно: https://www.azul.com/downloads/zulu/

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Я лично остаюсь на восьмёрке и просто не буду обновляться, если не найдётся серьёзный вендор. Мне нужна 32-битная джава, которая нормально работает на XP. Про обновляться раз в полгода это вообще несерьёзно.

Таких людей про «обновляться несерьезно» оказалось исчезающе малое количество. Проще на них забить.

мм.. как все сложно. У меня в федоре JDK «просто работает» из коробки и мне даже не приходило в голову, что с ней бывает нужно как-то изощряться

Если джава планируется запускаться от пользователя — то распаковывать в его домашнюю папку и прописывать экспорты в

Если джава планируется запускаться системно — то распаковываем куда-нибудь в корень (например, в /opt/jdk), переменные прописываем в /etc/profile.

За такой способ прописывания переменных в приличном обществе бьют по лицу. Особенно, если это сервак. Нормальные люди пишут wrapper script и кладут его в /usr/local/bin или в $HOME/.local/bin.

да неважно как $PATH записывать. Важно чтобы все зависело от тебя, а не от админа сервера (который может и не дать тебе права на bin), и не от создателя дистрибутива

более лучший вариант — Docker. Стараюсь теперь совершенно все запускать в нем.

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Вроде October 2020 для jdk8 это не очень уж и долго, всего на полтора года дольше чем Oracle Java 8. Но внимание, тынц на предыдущую версию этой страницы:

Срок поддержки для jdk7 продлили на 2 года, а для jdk8 оставили таким же, что есть очень нелогично, так как переход jdk7 -> jdk8 гораздо менее болезненный чем jdk8 -> jdk11. Отсюда логично предположить, что поддержку jdk8 тоже продлят года на 2. Шапка продает саппорт на ЖиБосс, и покупатели очевидно будут хотеть поддержку jdk8 на все время пока ЖиБосс не научится в jdk11 и пока все бузинесс-критикал приложения на jdk11 переведут (т.е. — никогда).

Пакетики в CentOS 7 == пакетики в шапке 7 (тупая пересборка). Пакетики в бубунте — ну очень похожи на пакетики из шапки помимо именования.

Рекомендую обновляться раз в полгода.

Ах-ха-ха, ну конечно, все жабаынтырпрайзы сразу запишутся в бета-тестеры. LTS версии есть для юзеров же. А у jdk8 есть все шансы стать «супер-LTS» по примеру Python 2.7.

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

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

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

Я лично остаюсь на восьмёрке и просто не буду обновляться

+1, как и руководства многих разумных ынтерпрайзных предприятий.

Про обновляться раз в полгода это вообще несерьёзно.

+2, если Партия будет заставлять обновляться каждые полгода на новую мажорную версию, то обновления будут происходить «на другой язык».

Мне нужна 32-битная джава, которая нормально работает на XP

Рекомендую мониторить следующие места на предмет jdk8-32-bit-оффтоп:

Из них AdoptOpenJDK — самое официальное место, там правда вроде нет сейчас 32-битных сборок, но они известные слоупоки и вполне могут добавить 32-бит позднее.

в отличие от бардака в веб-разработке, тут релизы релизят настоящие волшебники, и каких-то особых проблем с обновлениями быть не должно.

никаких left-pad, если ты об этом

На компьютере, с которого сейчас пишу, JDK 10.0.1 apt-get’ом нормально установился.

А вот Eclipse Photon я ставил в /opt ручками.

На работе в «продакшене» JRE и JDK ставлю только ручками.

PS. Еще ANT_HOME и M2_HOME тоже желательно указать.

В enterpriZe никакого «бардака» нет.

А есть Oracle и IBM.

Бардак — это LAMP — пых-пых, гвидопых и прочие кустарные поделия от кульхацкеров-одиночек.

Это ты сейчас на каком языке пишешь?

А есть какие-нибудь доки или мини-книжки/статьи про новые «фишки» в 9-10-11 java для тех, кто на ней редко пишет? Так сказать, понять, что нового по сравнению с 8-кой.

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

там везде есть раздел Features, где приведен список JEP, в которых четко и конкретно, грамотными людьми, описано — что это такое, зачем нужно, как посмотреть

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

А в 10 и 11 там по сути, всякая минорщина. Не факт что на ЛОРе бы про такое разрешили писать мини-новость.

Нет в этом ничего жуткого, необычного. Чего-то такого, что разработчики на почти любых других технологиях не видели бы при самых обычных обновлениях

Как обычно, истерят в основном белки-истерички

Ну, а как вообще, сообщество/опенсорс, пишет под 9-10-11 или всё медленно движется?

Если ты об backward compatibility, то все основные вещи давным-давно совместимы вплоть до 11. Специально собиралась статистика, были какие-то тэги в твиттере, но это уже не актуально. Всё просто работает. За исключением вещей вроде JavaEE и Nashorn.js, которых просто выбросили из JDK на мороз.

Основной дизастер был за пару месяцев до и после выхода 9 в прошлом году. После этого уже не было ченжей, чтобы что-то там поломалось. Ченжи вроде добавления Shenandoah GC приносят новые крутые фичи и не способны что-то поломать на уровне пользовательского API

Если ты о версии кода, то понятия не имею. Скорей всего, внедрение идет только на уровне совсем новых с смелых проектов, в том же Spring. Проблема в том, что forward compatibility нет, собранное под 11 не запустится на 8, и соответственно возникает вопрос — готовы ли проекты потерять всякий совсем кровавый ынтерпрайз из своих клиентов. Думаю что до выхода JDK 11 и сбора реальной статистики — сколько больших компаний перекатились с 8 на 11 — охотников будет немного.

Прямо сейчас охотники будут в end-user продуктах. Охотники среди системных либ подтянутся где-то через год, когда до значительной части сообщества дойдет озвученная выше мысль: обновляться можно и нужно, а сидеть на LTS — это удел совсем кровавых ынтерпрайзов с кромешным говнокодом. Сейчас вам это кажется дичью, но как говорится — «запомните этот твит» (с)

Кишори Шаран «Java 9. Полный обзор нововведений» для быстрого ознакомления и миграции. ДМК Пресс, 2018. ISBN 978-5-97060-575-2

Есть и не мини-книжки. Наиболее важное нововведение в Java 9 — система модулей. Надо ознакомиться с ней, чтобы решить, как использовать в своих разработках. Остальное больше относится к удобству. Но JDK 9, хоть он и новый, не имеет особого смысла использовать ввиду наличия JDK 10. В котором однако изменения в самом языке незначительны. Так что изучать нововведения можно по литературе о JDK 9, а пользоваться JDK 10. JDK 8 оставить для программ, которые ещё не проверены на совместимость с JDK 10.

Источник