Скомпилированный файл не запускается
Обновлено: 17.05.2024
Почему кажется, что я не могу открыть исполняемый файл, созданный на C++, дважды щелкнув по нему.
У меня есть файл, который я запустил из IDE, и я хотел бы знать, есть ли способ установить этот файл для открытия терминала при щелчке по нему, как это делает файл .exe в Windows.
Код C++, который я мог бы добавить в свой исходный код, который позволит это.
Настройте Мой ПК, чтобы открыть его.
Я стараюсь избегать наборов инструментов, насколько это возможно. Недавно я скомпилировал приложение для Windows (спасибо моему двоюродному брату, у него есть компьютер с Windows)
И было бы замечательно, если бы можно было сделать то же самое, что можно сделать в Windows на Linux, потому что у нас есть 2 Release Folders.
И я хотел бы, чтобы это простое приложение на основе терминала могло работать без необходимости быть экспертом.
Я добавил эту строку:
Он открывается на терминале, но просто показывает путь к файлу, а не саму программу.
Я ожидаю, что вам нужно установить "исполняемый" бит в файле, который выводится компилятором Linux C++, я не думаю, что это делается по умолчанию из соображений безопасности.
Просто "cd" в каталог, в котором находится ваш сгенерированный исполняемый файл.
Заменив "myexecutable" на имя вашего вывода компилятора.
Затем попробуйте запустить его с ./myexecutable
Я считаю, что это также должно сделать программу "работоспособной" с помощью щелчка мыши и консоли.
Точно так же, если вам нужно запустить "скрипт" из команд, вы можете попробовать следующее в файле скрипта, сохранить его как «myexe.sh» или что-то подобное:
Затем снова используйте
чтобы сделать так, чтобы вы могли запустить скрипт, нажав на него.
Я думаю, что корень вашей проблемы в том, что вы на самом деле не понимаете различия между эмулятором терминала и оболочкой и тем, как Linux выясняет, как запускать процессы.
Во-первых, это "Terminal Emulator", в среде на основе Gnome это обычно Gnome Terminal.
Затем есть "Shell", в Linux это обычно bash, хотя возможны и другие оболочки.
"Shell" работает внутри "Terminal Emulator". Это различие связано с возрастом физических терминалов, где физический терминал - это аппаратное обеспечение, которое принимает данные, пишет текст в цветах и т.д., А Shell - это программное обеспечение, которое обрабатывает пользовательские команды и управляет другими процессами на основе заданных команд.
В настоящее время у нас есть экран общего назначения, который может отображать любые изображения, поэтому мы больше не используем физический терминал, а вместо этого имеем "эмуляторы терминала", программное обеспечение, которое эмулирует работу физических терминалов, и оболочку, которая по-прежнему является та же самая оболочка, что и раньше (ну, современные оболочки используют преимущество программного эмулятора терминала, например, не ограничиваются физическим ограничением бумаги и т. д., но разрыв остается).
"Оболочка" не всегда работает внутри эмулятора терминала; Существуют также графические оболочки, такие как Nautilus (подсказка, Nautilus - название морского существа с большой раковиной) или Windows Explorer (не путать с Internet Explorer).
Как в оболочке командной строки, например, bash, так и в графической оболочке, например, Nautilus, исполняемый файл помечается установленным битом execute .
В командной строке вы можете использовать ls -l для просмотра битов прав доступа к файлу, например, rwxrwxrwx означает, что каждый может читать / писать / выполнять программу; rwxr-xr-- означает, что владелец имеет полное разрешение, люди в группе файла могут читать и выполнять, но не могут писать, а другие могут только читать файл. В Nautilus вы можете щелкнуть правой кнопкой мыши файл> Свойства> вкладка Разрешения. На странице свойств Разрешения вы можете получить разрешение для файла, подобное тому, которое есть в командной строке.
Файл с установленным битом выполнения рассматривается как исполняемый файл и может быть выполнен с помощью ./filename (оболочка командной строки) или двойного щелчка (графическая оболочка).
Наконец, есть несколько других тонкостей того, как оболочка выполняет файл. В большинстве оболочек Linux вы можете "выполнить" скрипт, написанный на python/perl/php/bash, который не является скомпилированным исполняемым файлом. Поскольку эти файлы не являются скомпилированными в исходном коде исполняемыми файлами, для их выполнения требуется интерпретатор (например, интерпретатор python). В отличие от оболочки Windows (Explorer), которая определяет интерпретатор для вызова через расширение файла; Оболочки Linux определяют правильного интерпретатора, глядя на строку "hashbang", которая выглядит следующим образом
когда бит выполнения файла установлен, и у файла есть эта строка hashbang, оболочка вызовет интерпретатор /usr /bin /python с текущим файлом в качестве аргумента.
Nautilus также может распознать, когда программа является приложением командной строки, и предложит вам запустить приложение в Терминале. Когда вы дважды щелкнете по исполняемому скрипту, Nautilus спросит, хотите ли вы запустить его в терминале, запустить без терминала или отредактировать файл в текстовом редакторе.
Всем привет. Написал маленькую программу для сбора информации о комплектующих ПК (мне это нужно по работе). Посредством самого python'а программа работает без каких-либо проблем, но если ее скомпилировать через "pyinstaller -F prog1.py", то получившийся exe-шник уже не запускается. Или запускается, но быстро закрывается, не отрабатывая как следует. Программа использует модуль WMI, думаю проблема с ним, т.к. любые другие программы отлично работают после компиляции.
Вот код программы:
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Не работает программа после компиляции
Вот сама программа: Все компилирует не выдавая ошибки и после компиляции "435.exe": Загружено.
Не работает программа после компиляции
После компиляции проекта не могу ничего делать. появляется главное окно и показывает что идет.
Программа работает только после компиляции
Доброго времени суток. Возникла проблема. Написал программу, базу создал в студии, привязал к.
А смысл, чем так не устраивает ? Qimer, где лог
Во вторых: WARNING: lib not found: api-ms-win-core-path-l1-1-0.dll
Установил api-ms-win-core-path-l1-1-0.dll. Пере"упаковал" программу. Толку 0.
Qimer, Меня вот это фраза смущает - "Установил api-ms-win-core-path-l1-1-0.dll". Куда ты это установил, pyinstaller не находит эту dll при упаковке, это означает что его ручками надо упаковать. Более того, чтобы явно понять в чем дело, включи консоль при упаковке и запусти exe файл через консоль, там ты увидишь явную причину, на что именно ругается упакованный скрипт.Нашел видос на ютьюбе, там чел рассказывал как установить эти библиотеки. Установил Redist C++ четатам и ребутнул комп. Но прблема не исчезла, так и не найдет эту библиотеку. Поискал еще на форумах и нашел как чел запускает это по команде
pyinstaller --paths "C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86" -F main.py
Сижу качаю эти Kits сейчас.
А вот что мне выдала консоль PyCharm при вызове моего исполняющего файла. Как и предполагалось, он не импортировал WMI.
(venv) D:\Python\dist>wmitest.exe
Traceback (most recent call last):
File "WMItest.py", line 1, in <module>
ModuleNotFoundError: No module named 'wmi'
[2096] Failed to execute script WMItest
Добавлено через 27 минут
Нифига. Почему то в этих Kits этой библиотеки нет. Хз что делать. DmFat, ты можешь у себя попробовать проделать то же самое? Я имею в виду упаковать программу и проверить будет ли она у тебя работать. Там только WMI модуль надо установить и все.
В этой статье содержится разрешение устранения неполадок для компиляторов Visual C++ или Visual C++ Linker.
Применяется к: Microsoft Visual C++ 2010 Express, Visual Studio
Исходный номер КБ: 974229
Действие
При расследовании возможной проблемы с компилятором Microsoft Visual C++ или линкером важно получить как можно больше сведений о процессе сборки и используемых параметрах. В этой статье рассмотрены некоторые советы по устранению неполадок, которые помогут решить проблему сборки или получить всестороннюю информацию для службы поддержки Майкрософт.
Решение
Для проблем компилятора, таких как внутренние ошибки компилятора (т. е. C1001), зависает или сбои, может быть полезно захватить выход препроцессора C/C++ для предоставления упрощенного репродуцируемый пример проблемы. В Visual C++ IDE это можно сделать, задав свойство Generate Preprocessed File with Line Numbers (/P) или Without Line Numbers (/EP/P). Это свойство можно найти на страницах свойств проекта в параметрах Configuration Properties, C/C++, Preprocessor.
Этот параметр можно установить на уровне проекта из меню Project Properties, в этом случае оно будет создавать файлы для всех исходных файлов в проекте или его можно установить для одного файла, щелкнув правой кнопкой мыши файл в проводнике решений, выбрав контекстное меню Properties, чтобы привести диалоговое окно свойств для одного .i файла.
Переключатель компилятора /P направляет CL.EXE для захвата вывода препроцессора в файл. Добавление /EP подавляет добавление сведений о номере строки в итоговом файле. /P достаточно, но /EP/P создает меньший файл вывода. Созданный файл вывода препроцессора будет иметь то же имя, что и исходный файл, который компилирован, но с расширением файла a.i, например, file1.cpp создает файл вывода препроцессора file1.i в том же каталоге.
При использовании этого коммутатора компиляция будет продолжаться до фазы препроцессора, то есть не будет создан файл компилятором, и вы можете получить ошибку ссылки, отражая тот факт, что файлы OBJ не могут быть .OBJ найдены.
Вы можете самостоятельно компилировать файл вывода препроцессора вне контекста Visual Studio проекта. Файл содержит все сведения о файле загона, замене макроса и сведениях директивы компиляторов, необходимых для компиляции этого конкретного или .i .C .CPP исходных файлов. Другими словами, это автономный модуль, который должен иметь возможность воспроизводить проблему компиляции без каких-либо зависимостей от других файлов. В результате файл часто будет большим и содержит большое количество белого пространства.
Проблемы со ссылками
Для проблем со ссылками (ошибки типа LNKxxxxx) можно использовать командный переключатель командной строки /LINKREPRO для создания тестового случая, содержащего только входные данные ссылок без зависимости от исходных файлов. /LINKREPRO использует следующий синтаксис:
'<path>' это полный путь к пустой папке в локальной файловой системе. Эта папка уже должна существовать — ссылка не создаст ее автоматически и создаст ошибку, если папка не существует.
Этот параметр не подвергается непосредственному воздействию в проектной системе. Чтобы добавить его в сборку, откройте меню свойства проекта из Project меню. В конфигурации Свойства , Linker, Командная строка , в поле Дополнительные параметры изменить, введите переключатель (в том числе вперед слэш) и заменить путь с уже существующей локальной папки /LINKREPRO:<path> пути. Пример: /LINKREPRO:C:\TEMP\LINKREPRO\ .
Если в этом окне редактирования уже есть другие параметры линкера, разделяйте их запятой.
Кроме того, можно использовать переменную LINK_REPRO среды. Если переменная среды существует, линкатор будет читать выходной путь из переменной среды и LINK_REPRO создавать linkrepro. Переключатель /LINKREPRO не требуется при использовании LINK_REPRO переменной среды. Использование LINK_REPRO переменной среды:
Откройте командную Visual Studio командную подсказку. Это устанавливается в меню Пуск, в Visual Studio папке под Инструменты Visual Studio подмастерье.
Создайте LINK_REPRO переменную среды, указывающую на существующий и пустой каталог, например: SET LINK_REPRO=C:\TEMP\LINKREPRO\ .
Запустите Visual Studio из той же командной подсказки, чтобы она разделяет копию измененной среды.
Откройте проект и перестроим весь проект.
Когда LINK.EXE вызывается в сборке, она копирует все необходимое для привязки проекта к каталогу linkrepro. Среди скопированные файлы будут ваши объектные файлы (. OBJ), необходимые файлы библиотеки (. LIB), включая библиотеки Майкрософт и файл ответа linker (LINK. RSP), чтобы ССЫЛКА больше не зависела от файла решения.
Чтобы подтвердить, что у вас есть все необходимые файлы для воспроизведения проблемы ссылок, можно запустить LINK в каталоге, указанном переменной LINK_REPRO среды, используя файл ответа linker, созданный linkrepro: LINK @link.rsp .
Перед этим используйте следующую команду, чтобы отключить эту функцию при использовании переменной среды командной строки: SET LINK_REPRO= .
Этот процесс также можно использовать для проверки файлов, участвующих в создании библиотеки, при использовании LIB.EXE link/LIB.
Заявление об отказе от ответственности
Быстрый отказ от публикации
Статьи быстрого публикации предоставляют сведения непосредственно из организации поддержки Майкрософт. Сведения, содержащиеся в этом ниже, создаются в ответ на возникающие или уникальные темы или предназначены для дополнения других сведений базы знаний.
Заявление об отказе от ответственности
Корпорация Майкрософт и(или) ее поставщики не делают никаких представлений или гарантий относительно пригодности, надежности или точности сведений, содержащихся в документах и связанных с ними графиках, опубликованных на этом сайте ("материалы") для любых целей. Эти материалы могут включать технические неточности или опечатки и могут быть пересмотрены в любое время без уведомления.
В максимальной степени, разрешенной применимым законодательством, Корпорация Майкрософт и/или ее поставщики дисклеймировали и исключали все представления, гарантии и условия, будь то экспресс- или подразумеваемые или нормативные, включая представления, гарантии или условия названия, отсутствие нарушения, удовлетворительное состояние или качество, торговая доступность и пригодность для определенной цели, в отношении материалов.
Репутация: нет
Всего: нет
Подскажите плз, что за ужасть случилась с моим проектом:
сегодня прихожу на работу, включаю vc++ 2005, моя прога компилируется, а отладочный exe запускаться не желает потому что
"Unable to start program . exe".
программка - win32 проект под winapi.
проверил другие проекты - идут и консольные и оконные.
во время компиляции ошибок не пишет. говорит что build sucsess, 0 errors, 0 warnings.
Пробовал просто сам ехе запустить через проводник, выскакивает окошко с надписью: . exe не является приложением win32.
Пробовал создать новый проект и туда исходник закинуть, всё равно не запускается.
Подскажите плз, в чем может быть дело?
Стал разбираться, пошел по истории исходников: неделю назад стал менять структуру программы т.к. нашел логическую нестыковку в модели и как только я начал менять структуру, сразу появилась такая фигня. Просто я не запускал программу пока блоки переделывал (всё равно бестолку), только компилировал чтобы на ошибки проверить.
В чем может быть дело?
Репутация: нет
Всего: 7
Репутация: нет
Всего: нет
да, манифесты стандартные (я про них даже и не знал ничего). Прога, которая до изменения структуры вполне себе работает, соответственно манифесты там генерируются правильно, после изменения exe не включается.
Репутация: нет
Всего: нет
Посмотрел манифест файлы той версии, которая работает - они точно такие же. Наверное дело в чем-то другом.
при пересоздании ехе пишется такая строка:
Репутация: нет
Всего: 7
Репутация: нет
Всего: нет
Репутация: 3
Всего: 3
Репутация: 13
Всего: 85
В main вначале пишете:
return 0;
компилируем,
Если опять не запускается, то копать опции проекта.
Если запускается, убираем return 0; и дебагером.
Репутация: нет
Всего: нет
Спасибо, return 0 сегодня попробую. Иначе похоже придется отсекать куски программы чтобы понять из-за какого куска неправильно компилируется.
(возможно где-то в структуре классов получилась циклическая ссылка друг на друга. не факт, но как вариант).
| Цитата |
Может быть собранный exe не win32, а win64 или еще что. Поглядеть на него pe просмотрщиком надо бы. |
Эта прога, вариант неделей раньше запускается (в этом же проекте просто перезаписываю cpp файл). Св-ва проекта не менял. Только изменил структуру классов и дописал несколько функций.
Сам проект win32.
А как включить репросмотрщик и что это?
Репутация: 33
Всего: 183
Может ему стало не хватать какой-нибудь DLL после этого? Dependence-вьюером его посмотри. причем полностью (рекурсивно, все зависимости).
У меня были ситуации, когда с какого-то перепуга проект цеплял DLL не той версии.
Dependence-viewer - это утилита, которая, как следует из названия, показывает все библиотеки, которые требуются для загрузки exe. Должна быть в составе MSVC (называется Depends.exe), но есть и куча других, только свистни гуглу. Полезно иметь в арсенале программиста.
Репутация: нет
Всего: нет
Посмотрел через Depends view:
IESHIMS.DLL не удается найти указанный файл (2)
WER.DLL не удается найти указанный файл (2)
MPR.DLL просто значок красный (может активный?)
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
этот IESHIMS.DLL и wer.dll вызываются из setupapi.dll-> shell32.dll -> shdocvw.dll -> mshtml.dll -> iframe.dll
Дополнение: посмотрел exe файл недельной давности. Те же файлы пишутся ненайденными, но всё работает (странно).
В mpr.dll функция WNetRestoreConnectionA помечена красным.
Репутация: 99
Всего: 106
т.е., я так понимаю на работе стоит что-то выше XP?
Добавлено через 4 минуты и 29 секунд
хотя, нет, наверное даже не так: компилируется в конфигурации для чего-то выше чем XP (ну и соответственно, на чем-то выше XP, раз сборка таки проходит удачно), а запускается на XP и ниже?
Добавлено через 12 минут и 39 секунд
а может все проще: это реально не win32, а WOW64, и это не ошибка приложения, а ошибка совместимости, т.е. этот exe можно запускать только на 64-битных осях
"Гений всегда разумнее, чем умнее. Ум — это машина, разум — водитель этой машины."
Репутация: нет
Всего: нет
Нет, у меня XP SP3.
Прога (вариант неделей раньше) компилируется и запускается на этой же машине, в ней просто заменяю основной cpp файл. Cам проект win32.
Делаю без всяких заморочек. VC++ и winapi. Прога со стороны программирования примитивнейшая (расчеты и вывод), никаких изысков.
Репутация: нет
Всего: нет
Разобрал прогу, оставил только структуру классов - не работает. Перекинул структуру классов в новый сгенерированный проект (только основное окно и менюшка).
Потом стал уже отключать классы по очереди. На одном из классов пограмма заработала. Стал подключать классы обратно - программа всё равно работает.
между включениями удалял каталог debug c exe файлом. Единственное, что удалось засечь - это строку
когда программа не запускалась.
замучился. посмотрите плз, в чем дело. Выкладываю максимально урезнный код - часть структуры классов в сгенерированном проекте win32 оконном. Этот вариант компилируется, но не запускается:
//КОНСТАНТЫ
const int MNS=5;
const long MND=10000;
const int RMP=50;
const int MNAD=MNS*2*50;
const int DemStatusSize=MNS*4+1;
Tick LastPrice;
res res1;
hInst = hInstance; // Store instance handle in our global variable
Репутация: 13
Всего: 85
Покажите как определены макросы, (и определены ли?)
_WIN32_WINNT
WINVER
Скорей всего, дело в них.
Они находятся либо в "stdafx.h" либо в "targetver.h"
Также определить этот макрос можно с помощью параметра компилятора /D,
так что и командную строку не помешает посмотреть.
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Chipset, Step, Fixin, GremlinProg, xvr. feodorv.
[ Время генерации скрипта: 0.1492 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Сгенерированный исполняемый файл иногда не запускается при сборке с параметрами rustc -Ctarget-feature=+avx -Copt-level=2 -Clto .
Я пробовал этот код:
Скомпилирован с помощью следующего сценария оболочки:
Когда я запускал сгенерированный исполняемый файл main несколько раз, выполнение программы останавливалось (не завершалось и ничего не выводилось; даже не входило в функцию main ) 5 из 100 раз.
Когда я запускал исполняемый файл из lldb , я мог видеть, что EXC_BAD_ACCESS произошло из-за попытки загрузить 32-байтовый блок из невыровненной памяти с помощью vmovdqa (что требует адрес операнда должен быть выровнен по 32 байтам).
rustc --version --verbose :
Результат sample (инструмент, поставляемый с macOS), когда программа остановлена:
Анализ
После оптимизации этот вызов внутренней функции copy_nonoverlapping переводится в следующую инструкцию LLVM:
Это переведено в следующую инструкцию x86_64:
Самый полезный комментарий
Сузили код, чтобы воспроизвести проблему. Проблема может быть воспроизведена с помощью -Ctarget-feature=+avx -Copt-level=2 --extern libc=<environment dependent value> :
Это не было ни rustc ни оптимизацией LLVM; все это было связано с тем, как локальные переменные потока (TLV) обрабатываются dyld macOS.
LLVM ожидает, что глобальные переменные (включая локальные потоки) будут выровнены, как указано:
Это не обязательно должно быть align 32 само по себе, но, возможно, LLVM все равно решила сделать его align 32 потому что таким образом, я полагаю, можно было бы лучше оптимизировать программу, используя выровненную загрузку / хранение. Но в любом случае это делает законным использование align 32 для всех загрузок / сохранений этой переменной следующим образом:
И он выводит секцию Mach-O для TLV с надлежащим требованием выравнивания:
Проблема в том, что dyld threadLocalVariables.c фактически не принимает во внимание информацию о выравнивании при выделении области памяти для TLV:
Вышеупомянутая программа завершится ошибкой, если возвращенный buffer оказался не выровненным по 32 байтам.
Читайте также: