Почему ось не видит экзешника в папке, хотя он там есть?

Друзья! То есть я подозреваю что тут без знания низкоуровневого программирования тут не обойтись; для начал гляньте на скриншот, как вам это нравится?

Так, я смотрел ProcessExplorer, там такая цепочка процессов вырисовывается:
g++.exe-> cc1plus.exe
Отец и сын соответственно

Еле-еле научился приаттачиваться к cc1plus потому, что он скоротечен и вот тут начинается самое интересное. Приаттачиваюсь к cc1plus, трассирую по шагам, дохожу до

Код (Text):

1. call EXitProcess

То есть всё, следующим шагом cc1plus убьётся. Жму F8- ноль эмоций, после закрываю OllyDbg и появляется в консоли надпись что g++ нет такого файла или директории

Что мне делать, скажите пожалуйста?

 

amvoz
Не очень понял, что Вас смущает. g++.exe пытается запустить какой-то процесс, но не находит образ. Видимо, соответствующего пути в переменной PATH не хватает.

 

Посмотрите, пожалуйста, внимательнее на рисунок.
Первая команда "dir" выводит список файлов в текущей директории, среди них есть и g++, я стрелкой эту строчку обозначил

Так, а вторая команда говорит, что g++ в директории нет, это я тоже стрелкой обозначил.
Вот и противоречие.

 

amvoz
Перечитайте ещё раз, что я написал.

 

Вы что, хотите сказать, что он ищет файл с названием CreateProcess?

 

amvoz
Я хочу сказать, что "g++.exe пытается запустить..." Не его, а он. А что именно, смотрите в ollydbg. Например, запустите cmd под ollydbg, предварительно выставив птичку "Debug child processes". При попытке запуска g++ откроется новое окно ollydbg с g++. Там поставьте брейкпоинты на CreateProcessA/W . Когда стопорнётся, смотрите параметры в стеке.

 

А чё бы сразу не запускать в отладчике g++?
А впрочем, не суть. Дочерний у него процесс один, это cc1plus. Я наблюдал это в ProcessExplorer, он создаётся и заканчивается. И в OllyDbg тоже брякается на CreateProcess ровно один раз, при создании (удачном) cc1cplus

 

amvoz

Для чистоты эксперимента. Строку "g++.exe: CreateProcess: No such file or directory" выводит сам g++.

 

понимаете, у меня нет "Debug child processes"...

 

ну то есть я могу попробовать зациклить EnyryPoint в g++ и потом приаттачиться к нему, но хотелось бы всё же штатные инструменты использовать, а я чё-то их не найду.

 

amvoz

Версия ollydbg вторая? Если нет, то качайте вторую. Там есть.

 

Пути у тебя не прописаны, и g++ не может запустить cc1plus - пытается (поэтому на CreateProcess точка останова срабатывает), но не может т.к. не находит его.
Прежде чем что-то дебажить вбей в Google сообщение об ошибке и почитай что пишут.

 

cppasm, ты что?

...Так, я смотрел ProcessExplorer, там такая цепочка процессов вырисовывается:
g++.exe-> cc1plus.exe
Отец и сын соответственно

ЭТО я в первом сообщении написал

Хз, может я непонятен, но cc1plus.exe вызывается и срабатывает НОРМАЛЬНО (и в OllyDbg тоже это я наблюдал).
А вот дальше ПОСЛЕ УДАЧНОГО вызова cc1plus грязь какая-то. И да, API-функция CreateProcess вызывается в g++ ОДИН РАЗ, для создания cc1plus

А второй раз не вызывается. Ила так: вызывается, но как-то хитро, обходными путями. То есть ни бряка, ни полбряка не срабатывает, а сообщение выдаётся. И непонятно, какой именно образ ищет g++. Безымянный какой-то.

 

amvoz
попробуйте

Код (Text):

1. g++.exe E:\Dev-Cpp\Bin\main.cpp

 

gorodon, от безысходности разве что. Впрочем, так тоже пробовал, не помогает.
////////////////////////////////////////////////////////////////////////////////

Ребята, я обнаружил грязь. По совету l_inc качнул OLlyDbg200, где запускал cmd и отслеживал его дочерние процессы, а точнее один- g++. Так вот, этот g++ подло себя ведёт. Он раз 20, не считал я толком вызывает CreateFile с параметром OPEN_EXISTING- а таких файлов не было и нет у меня на компе! Естественно, все эти вызовы функции CreateFile заканчиваются крахом, так а после очередного краха выводится собщение то самое из первого поста!!

Причём где он только не ищет эти файлы, лезет даже в C:\MASM! (кто его просит?)

Вот некоторые из файлов, какие он ищет у меня на компе:

"C:/msys/1.0/var/tmp/gettext-reloc-yA4108/mingw/share/locale/locale.alias"
"C:/msys/1.0/var/tmp/gettext-reloc-yA4108/mingw/local/share/locale/locale.alias"
"/mingw/share/locale/ru_RU/LC_MESSAGES/gcc.mo"
"/mingw/share/locale/ru/LC_MESSAGES/gcc.mo"
"CONOUT$"

И прочая и прочая и прочая, заканчивается всё поиском какого-то коротышки "as", который ищется во всех системных директориях, потом текущей директории (всё, напомню, OPEN_EXISTING), потом крах!

Умные головы, подскажите, чё делать?

 

amvoz
"Коротышка as" — это компилятор ассемблера из binutils. g++ должен иметь к нему доступ. Поиск во всех системных директориях — это поиск файла во всех директориях, указанных в соответствующей переменной окружения (предположительно PATH, как я уже написал в посте #2). Думаю, достаточно просто перед запуском g++ в cmd написать set PATH=[путь к папке bin дистрибутива];%PATH%

 

Да не, таких файлов у меня отродясь не было на компе, в том-то и дело. Так что тут хоть запрописывайся пути, если файлов нет, то он их не найдёт. А они и прописаны, кстати, я ничё из переменной Path не удаляю, только прибавляю.
......................................................
Я уже где-то говорил, что путь к папке bin дистрибутива, прописанный в path влияет на то, чтобы запустить, допустим g++ из консоли в любой директории.
Впрочем, всё пропсано в Path

Если компилировать по F9 то достаточно этот путь прописать в параметрах IDE
as.exe есть, да. Но он ищет ещё и as просто.

Проблема наверное в том, что почему экзешники (тот же g++) обращаются к некоторым файлам. Они что,устанавливали их что ли?

 

amvoz

А путь к папке, в которой находится as.exe, перед вызовом g++ в PATH присутствует?

 

ага, присутствует. Но теперь новая напасть:

Код (Text):

1. E:\Dev-Cpp_nomingw\bin>g++ ra_0.cpp
2. e:/dev-cpp_nomingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot find -luser32
3. collect2: ld returned 1 exit status

Устаю я уже от этого всего. Искал-искал luser32 отдельно не нашёл. Самое-то главное меня мысльсвербит, что я теперь не смогу воспользоваться обновлениями пакетов, которые предлагает Dev-Cpp, скачал что-то новое и геммор на неделю

 

amvoz
-luser32 — это не файл, а ключ линкера. Означает, что линкер должен подключить библиотеку libuser32.a, которую он соответственно и не находит.