Windows h no such file or directory gcc

Common C++ Error Messages #1 – No such file or directory

Introduction

In this intermittent series, I’ll be looking at the most common error messages your C++ compiler (and linker) can produce, explaining exactly what they mean, and showing how they can be fixed (or, better still avoided). The article will specifically talk about the errors produced by the GCC command line compiler, but I’ll occasionally provide some coverage of Microsoft C++ as well. The articles are aimed at beginner to intermediate C++ programmers, and will mostly not be OS-specific.

Error Messages 101

Compiler error messages from the GCC g++ compiler generally look like something this:

which was produced by this code:

The first line of the error says which function the following error(s) is in. The error message itself comes in four main parts; the file the error occurs in, the line number and character offset at which the compiler thinks the error occurs, the fact that it is an error, and not a warning, and the text of the message.

As well as error, the compiler can also produce warnings. These are usually about constructs that, while not being actually illegal in C++, are considered dubious, or constructs that the compiler has extensions to cover. In almost all cases, you don’t want to use such constructs, and you should treat warnings as errors; in other words, your code should always compile with zero warnings. You should also increase the level of warnings from the compiler’s default, which is usually too low. With g++, you should use at least the -Wall and -Wextra compiler options to do this:

No such file or directory

The error I’m looking at today most commonly occurs when you are including a header file using the preprocessor #include directive. For example, suppose you have the following code in a file called myfile.cpp:

and you get the following error message:

What could be causing it? Well, the basic cause is that the compiler cannot find a file called myheader.h in the directories it searches when processing the #include directive. This could be so for a number of reasons.

The simplest reason is that you want the compiler to look for myheader.h in the same directory as the myfile.cpp source file, but it can’t find it. this may be because you simply haven’t created the header file yet, but the more common reason is that you either misspelled the header file name in the #include directive, or that you made a mistake in naming the header file when you created it with your editor. Look very closely at the names in both the C++ source and in your source code directory listing. You may be tempted to think «I know that file is there!», but if the compiler says it isn’t there, then it isn’t, no matter how sure you are that it is.

This problem is somewhat greater on Unix-like system, such as Linux, as there file names are character case sensitive, so Myheader.h, MyHeader.h, myheader.h and so on would all name different files, and if you get the case wrong, the compiler will not look for something «similar». For this reason, a very good rule of thumb is:

Never use mixed case when naming C++ source and header files. Use only alphanumeric characters and the underscore when naming C+++ files. Never include spaces or other special characters in file names.

Apart from avoiding file not found errors, this will also make life much easier if you are porting your code to other operating systems which may or may not respect character case.

The wrong directory?

Another situation where you may get this error message is if you have split your header files up from your C++ source files into separate directories. This is generally good practice, but can cause problems. Suppose your C++ project is rooted at C:/myprojects/aproject, and that in the aproject directory you have two sub-directorys called src (for the .cpp files) and inc (for the header files), and you put myfile.cpp in the src directory, and myheader.h in the inc directory, so that you have this setup:

Now if you compile the source myfile.cpp from the src directory, you will get the «No such file or directory» error message. The C++ compiler knows nothing about the directory structures of your project, and won’t look in the inc directory for the header. You need to tell it to look there somehow.

One thing some people try when faced with this problem is to re-write myfile.cpp so it looks like this:

or the slightly more sophisticated:

Both of these are a bad idea, as they tie your C++ code to the project’s directory structure and/or location, both of which you will probably want to change at some point in the future. If the directory structure does change, you will have to edit all your #include directories.The better way to deal with this problem is to tell the compiler directly where to look for header files. You can do that with the compiler’s -I option, which tells the compiler to look in the specified directory, as well as the ones it normally searches:

Now the original #include directive:

will work, and if your directory structure changes you need only modify the compiler command line. Of course, writing such command lines is error prone, and you should put such stuff in a makefile, the use of which is unfortunately outside the scope of this article.

Problems with libraries

Somewhat similar issues to those described above can occur when you want to use a third-party library. Suppose you want to use the excellent random number generating facilities of the Boost library. If you are copying example code, you may well end up with something like this in your C++ source file:

This will in all probability lead to yet another «No such file or directory» message, as once again the compiler does not know where «boost/random.hpp» is supposed to be. In fact, it is one of the subdirectories of the Boost installation, and on my system I can get the #include directive to work using this command line:

where /prog/boost1461 is the root directory for my specific Boost library installation.

Can’t find C++ Standard Library files?

One last problem that beginners run into is the inability of the compiler to find header files that are part of the C++ Standard Library. One particular favourite is this one:

where you are learning C++ from a very, very old book. Modern C++ implementations have not contained a file called iostream.h for a very long time indeed, and your compiler is never going to find it. You need to use the correct, standard names for such headers (and to get a better book!):

If this still fails, then there is almost certainly something very wrong with your GCC installation. The GCC compiler looks for Standard Library files in a subdirectory of its installation, and locates that directory relative to the directory containing the compiler executable, so if the Standard Library headers are available, the compiler should always find them.

Conclusion

This article looked at the «No such file or directory» message of the GCC C++ compiler. If you get this message you should:

• Remember that the compiler is always right in situations like this.
• Look very closely at the file name to make sure it is correct.
• Avoid naming file using mixed-case or special characters.
• Use the -I compiler option to tell the compiler where to look for files.
• Make sure that GCC is correctly installed on your system.

Источник

g++:error:CreateProcess:No such file or directory #26

Whenever i try to compile my C++ program. It give error:

g++:error:CreateProcess:No such file or directory.

Please help. Thank you

The text was updated successfully, but these errors were encountered:

Window load time: 791ms
activate()
platform win32

What happens if you enter

in the command prompt?

sorry for late reply

What happens when you enter

in the command prompt?

same error
g++: error: CreateProcess : No such file or directory

Sorry for the month long reply, but I am unable to reproduce this issue so I cannot help.

I have also faced the same problem while setting up Atom for C++ on Window 10. But later I found out that my MinGW was copied from Codeblocks folder. Reinstalling the packages through official MinGW installer and adding the directory path (for my case C:MinGWbin) in

Advance System Settings>Environment Variables > Path

solved the problem for me.

please can you help me out, mine is gcc: error: create process: No such file directory

yes. i got the answer. change the gcc to g++

I have experienced this problem before. The root cause is an exe file was unziped failed with the size zero. I tried another unzip tool to solved it.

For the problem, to know how it happened is important:
CreateProcess is a API to create a process, so the error indicated that the image file used to create the process may not exist.

How to solve it:
Add «-v» flags to run gcc/g++ to compile and then, the verbose log shows. We can find which file not exists. If nothing goes wrong, we can just run the last command in the verbose log with flag «-v» to continue to check recursively.

Источник

CreateProcess: нет такого файла или каталога

Я получаю эту ошибку всякий раз, когда я пытаюсь запустить GCC вне его каталога установки ( E:MinGWbin ).

Итак, допустим я в E:code и иметь файл с именем one.c . Бегущий: gcc one.c -o one.exe даст мне эту ошибку:

единственным обходным путем является переход в каталог установки, запуск gcc оттуда и указание всех других путей. Моя переменная окружающей среды Path содержит E:MinGWbin .

любые предложения по устранению этой проблемы? Я запуск Windows XP SP3.

24 ответов

его специально сказали, что вам нужно перезагрузиться после установки переменных среды в windows для migwin.

У меня была аналогичная проблема, вызванная не установкой компилятора C++. В моем случае я собирал .cpp-файлы для расширения Python, но компилятор сначала вызывается как c:mingwbingcc — . исполняемый.

внутренне, gcc.exe заметит, что его попросили скомпилировать .файл cpp. Он попытается вызвать g++.exe и сбой с тем же сообщением об ошибке:

gcc.exe: CreateProcess: нет такого файла или каталога

по данным код:: блоки wiki, вам необходимо добавить C:MinGWlibexecgccmingw32MinGW-Version на PATH . Нет необходимости перезапускать, но вам нужно открыть другой терминал, чтобы получить новейший PATH настройки.

для MinGW-w64 это libexecgccx86_64-w64-mingw32.7.0

У меня просто была эта проблема.

в моем случае проблема была связана с проблемами при загрузке пакетов для GCC. Программа mingw-get думала, что закончила загрузку, но это не так.

Я хотел обновить GCC, поэтому я использовал mingw-get, чтобы получить более новую версию. По какой-то причине mingw-get думал, что загрузка для определенного файла закончена, но это не так. Когда он пошел, чтобы извлечь файл, я думаю, он выдал ошибку (которую я даже не потрудился посмотреть-я просто запустите «mingw-get update && mingw-get install mingw32-gcc» и оставьте его там).

чтобы решить, я удалил gcc, выполнив «mingw-get remove mingw32-gcc» , а также удалил файл пакета (тот, который mingw-get не полностью загрузил), который был в папке кэша mingw («C:MinGWvarcachemingw-getpackages» в моей системе), затем снова запустил команду install. Он загрузил и установил недостающие части GCC (он не полностью загрузил пакет GCC-core).

Что решена моя проблема.

интересно, что mingw-get был достаточно умен, чтобы продолжить загрузку GCC-core даже после того, как я удалил файл пакета в папке кэша, а также удалил пакет mingw32-gcc.

Я думаю, что более фундаментальной проблемой было то, что, поскольку файлы GCC-core не были установлены, cc1 не было. И gcc использует cc1. Я предполагаю, что, когда gcc попытался запустить cc1, он использовал CreateProcess где-то, проходя путь cc1, который не был путем существующий файл. Таким образом, сообщение об ошибке.

у меня была точно такая же проблема.

после перепроверки моего PATH , Я понял, что установил оба Mingw (64 bit) и Cygwin (32 бит). Проблема в том, что оба Mingw и Cygwin есть g++ .

отключив пути Cygwin , ошибка исчезла.

Итак, это глупое сообщение об ошибке, потому что оно не говорит вам что файл, который он не может найти.

выполните команду еще раз с подробным флагом gcc -v чтобы увидеть, что gcc до.

в моем случае случилось так, что он пытался позвонить cc1plus . Я проверил, у меня его нет. Установил компилятор mingw на C++, а затем сделал.

получал то же сообщение об ошибке при попытке запуска из Cygwin со ссылками на установку mingw.

используя ту же установку mingw32-make-3.80.0-3.exe от http://www.mingw.org/wiki/FAQ и опция оболочки mingw из Start — > Programs — > на WinXP SP3 и gcc работает нормально.

эта проблема заключается в том, что вы используете материал суффикса верхнего регистра.C вместо строчных букв.c при компиляции с помощью Mingw GCC. Например, когда вам это нравится:

затем вы получите сообщение: gcc: CreateProcess: No such file or directory

но если вы это сделаете:

затем он работает. Я просто не знаю, почему.

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

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

Я испытал аналогичную проблему. Первоначально добавление папки bin GCC в мой системный путь не решило проблему. Я нашел два решения.

первым было запустить пакетный файл, который я нашел в корне установки MinGW, mingwbuilds.летучая мышь. Он (по-видимому) запускает командную строку, настроенную правильно для запуска GCC. Во-вторых, удалить двойные кавычки из папки GCC install bin, которую я добавил в переменную пути пользователя. Я попробовал это после того, как заметил партию файл не использует двойные кавычки вокруг пути установки bin.

Я случайно нашел пакетный файл во время просмотра дерева папок установки, пытаясь найти различные исполняемые файлы, которые не запускались (в соответствии с выходом-v). Я нашел некоторую информацию о MinGW wiki,http://www.mingw.org/wiki/Getting_Started, в разделах предостережения и параметры среды, это указывает, почему установщик MinGW не настраивает систему или путь пользователя для включения папки установки. Они, похоже, подтверждают, что пакетный файл предназначен для запуска командной строки, подходящей для запуска GCC из командной строки Windows.

в «дайте человеку рыбу, накормите его на день; научите человека рыбачить, избавьтесь от него на весь уик-энд» Вена,

показывает параметры компилятора. Опция g++ — v помогает:

просмотрите выходные данные для фиктивных путей. В моем случае исходная команда:

сгенерированный выход, включая этот маленький драгоценный камень:

что объясняет сообщение «Нет такого файла или каталога».

в «../lib/gcc/arm-none-eabi/ 4.5.1 / » сегмент исходит из встроенных спецификаций:

у меня был очень длинный путь, и где-то там есть файл (не gcc.exe) но другой файл, этот gcc.exe получает доступ из пути..

поэтому, когда я очистил путь, он работал

^^ таким образом, запуск gcc оттуда определенно запустит gcc ming.exe

компиляция я получил эту ошибку

мой путь был огромен

C:MinGWbin > путь / grep-io «ming»

у него не было мин там.

C:MinGWbin > Эхо мин / grep-io » мин» Минг!—9—>

(и да, что grep работает..путь не есть мин есть)

очистка моего пути полностью, привел его к работе!

Итак, пока не ясно, что именно было на пути, который привел к столкновению. Какой каталог, какой файл.

обновление-

выше, кажется, правильно для меня, но добавить, это также не простой случай чего-то ранее на пути столкнулись.. потому что обычно текущий каталог имеет приоритет. И это происходит здесь, поскольку GCC — version показывает, что он запускает ming, а не один из них в конфликтующем каталоге. Так что есть что-то забавное, если конфликтующий каталог находится в пути) , нужно либо сделать .gcc или добавить . к началу пути или добавить c:MinGWbin перед любыми конфликтующими каталогами в пути. это так, даже когда вы находитесь в C:MinGWbin и вот странный. И когда он дает ошибку, он все еще работает gcc Ming, но (по какой-то причине) смотрит на конфликтующий каталог, как я вижу из process monitor. Здесь может быть больше ответа http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista в ссылке, упомянутой в самом ответе здесь

глядя на Ming 64bit, вероятно, имеет ту же проблему, но я вижу, интересно, что он поставляется с bat-файл, который (разумно) фактически помещает каталог bin в терпкий путь. И похоже, что это стандартный способ правильной работы Ming gcc.

Code::blocks IDE (разумно) также помещает каталог bin в начале пути. Если вы запустите программу C, которая показывает переменные среды, вы увидите это.

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

-v опция не дала никаких дополнительных подсказок.

пришлось прибегнуть к procmon и чтобы иметь возможность найти корень проблемы.

сброс g++ активность файла процесса выявила многочисленные попытки найти cc1plus исполняемый файл по разным путям. Среди них были пути к старой версии GCC.

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

наконец, устаревший путь был найден в переменной среды system %PATH%. После его удаления, новая версия работает без ошибок.

добавить E:MinGWbin до PATH переменной.

похоже, что есть несколько дистрибутивов выпуска для MinGW. Какой вам попробовать? Для записи я столкнулся с той же проблемой, что и OP, и дистрибутив, который я получил, был от TDM-GCC 4.5.1.

Я нашел дистрибутив MinGW здесь кажется, работает намного лучше и настраивает все правильно. Поэтому для тех, кто сталкивается с этой задержанной ошибкой «createprocess-no-such-file-or-directory» и не может заставить вещи работать, удалите существующий MinGW и попробуйте тот, который я связал вместо.

У меня была такая же проблема (я запускаю cygwin)

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

я запускал pip install из Cygwin виртуального env для установки Django sentry..

решение для меня-это просто:

когда вы сохраняете программу, скажем, ее имя привет.cpp положите его в папку, например,xxl сохраните вашу программу.

вырезать эту папку и поместить ее в папку bin mingw.

при вызове программы:

эта проблема может возникнуть, если у вас есть разные версии программ.

например, у вас есть 1-летний gcc и вы хотите скомпилировать исходный код на C++. Если вы используете mingw-get установка g++ , gcc и g++ внезапно будут разные версии, и вы, вероятно, окажетесь в этой ситуации.

под управлением mingw-get update и mingw-get upgrade решил этот вопрос для меня.

(ссылаясь на оригинальную проблему)
Сегодняшняя версия mingw (см. дату поста)
Все, что мне нужно было сделать, это установить путь в той же оболочке, в которой я бежал gcc .
Мне потребовался час, чтобы вспомнить, как установить DOS variables .

У меня была такая же проблема, и я пробовал все без результата, что исправило проблему для меня, это изменение порядка путей библиотеки в переменной PATH. У меня был cygwin, а также некоторые другие компиляторы, поэтому между ними, вероятно, было какое-то столкновение. Что я сделал, так это положил C:MinGWbin; путь сначала перед всеми другими путями, и это исправило проблему для меня!

попробуйте поместить путь в системные переменные вместо ввода пользовательских переменных в переменные среды.

я получал это сообщение об ошибке, потому что я использовал MinGW-w64 и команды в bin У всех был странный префикс. Я попытался вызвать исполняемые файлы в каталогах «целевой псевдоним», а не в bin каталоги, что привело к еще большим проблемам. Это нет-нет согласно часто задаваемые вопросы. Тогда решение для меня заключалось в создании символических ссылок на все команды с префиксами. Я открыл командную строку с повышенными правами и использовал что-то вроде mklink gcc.exe x86_64-w64-mingw32-gcc.exe для каждого исполняемого, и теперь моя сборка работает.

хотя сообщение старое, у меня была та же проблема с mingw32 vers 4.8.1 на 2015/02/13. Компиляция с использованием Eclipse CDT не удалась с этим сообщением. Пытаюсь из командной строки с опцией-V также не удалось. Я также отсутствует исполняемый cc1plus.

причиной: Я загрузил командную строку и графический установщик с сайта mingw32. Я использовал это для первоначальной установки mingw32. Используя GUI, я выбрал базовые инструменты, выбрав как c, так и c++ компиляторы.

этот установщик сделал неполную установку 32-битного компилятора C++. У меня были файлы g++ и cpp, но не исполняемый файл cc1plus. Попытка сделать «обновление» не удалась, потому что установщик предположил, что у меня все установлено.

чтобы исправить я нашел эти сайты: http://mingw-w64.sourceforge.net/ http://sourceforge.net/projects/mingw-w64/ Я загрузил и запустил эту «онлайн-установку». Конечно, в этом были недостающие файлы. Я изменил переменную моего пути и указал на папку «bin», содержащую исполняемый файл g++. Перезагрузившей. Установлен 64 бит Eclipse. Открыл Eclipse и программу «Hello World» c++, скомпилированную, выполненную и отлаженную должным образом.

Примечание: 64-битный установщик, кажется, по умолчанию для настроек UNIX. Почему установщик определит ОС. Обязательно измените их.

Я провел целый вечер, занимаясь этим. Надеюсь, это кому-то поможет.

У меня была та же проблема.

У меня уже был компилятор g++, установленный через MinGW (пакет mingw32-gcc-g++) но мне нужен был компилятор C, поэтому я запустил mingw-get-setup.exe, где я смог его установить mingw32-базы пакет с компилятором.

увы! У меня была эта ошибка, когда я использую gcc для компиляции:

gcc: ошибка: createprocess: нет такого файла или каталога

Источник

Introduction

In this intermittent series, I’ll be looking at the most common error messages your C++ compiler (and linker) can produce, explaining exactly what they mean, and showing how they can be fixed (or, better still avoided). The article will specifically talk about the errors produced by the GCC command line compiler, but I’ll occasionally provide some coverage of Microsoft C++ as well. The articles are aimed at beginner to intermediate C++ programmers, and will mostly not be OS-specific.

Error Messages 101

Compiler error messages from the GCC g++ compiler generally look like something this:

main.cpp: In function 'int main()':
main.cpp:4:12: error: 'bar' was not declared in this scope

which was produced by this code:

int main() {
    int foo = bar;
}

The first line of the error says which function the following error(s) is in. The error message itself comes in four main parts; the file the error occurs in, the line number and character offset at which the compiler thinks the error occurs, the fact that it is an error, and not a warning, and the text of the message.

As well as error, the compiler can also produce warnings. These are usually about constructs that, while not being actually illegal in C++, are considered dubious, or constructs that the compiler has extensions to cover. In almost all cases, you don’t want to use such constructs, and you should treat warnings as errors; in other words, your code should always compile with zero warnings. You should also increase the level of warnings from the compiler’s default, which is usually too low. With g++, you should use at least the -Wall and -Wextra compiler options to do this:

g++ -Wall -Wextra myfile.cpp

No such file or directory

The error I’m looking at today most commonly occurs when you are including a header file using the preprocessor #include directive. For example, suppose you have the following code in a file called myfile.cpp:

#include "myheader.h"

and you get the following error message:

myfile.cpp:1:22: fatal error: myheader.h: No such file or directory
compilation terminated.

What could be causing it? Well, the basic cause is that the compiler cannot find a file called myheader.h in the directories it searches when processing the #include directive. This could be so for a number of reasons.

The simplest reason is that you want the compiler to look for myheader.h in the same directory as the myfile.cpp source file, but it can’t find it. this may be because you simply haven’t created the header file yet, but the more common reason is that you either misspelled the header file name in the #include directive, or that you made a mistake in naming  the header file when you created it with your editor. Look very closely at the names in both the C++ source and in your source code directory listing. You may be tempted to think «I know that file is there!», but if the compiler says it isn’t there, then it isn’t, no matter how sure you are that it is.

This problem is somewhat greater on Unix-like system, such as Linux, as there file names are character case sensitive, so Myheader.h, MyHeader.h, myheader.h and so on would all  name different files, and if you get the case wrong, the compiler will not look for something «similar». For this reason, a very good rule of thumb is:

Never use mixed case when naming C++ source and header files. Use only alphanumeric characters and the underscore when naming C+++ files. Never include spaces or other special characters in file names.

Apart from avoiding file not found errors, this will also make life much easier if you are porting your code to other operating systems which may or may not respect character case.

The wrong directory?

Another situation where you may get this error message is if you have split your header files up from your C++ source files into separate directories. This is generally good practice, but can cause problems. Suppose your C++ project is rooted at C:/myprojects/aproject, and that in the aproject directory you have two sub-directorys called src (for the .cpp files) and inc (for the header files), and you put myfile.cpp  in the src directory, and myheader.h in the inc directory, so that you have this setup:

myprojects
  aproject
    inc
      myheader.h
    src
      myfile.cpp

Now if you compile the source myfile.cpp from the src directory, you will get the «No such file or directory» error message. The C++ compiler knows nothing about the directory structures of your project, and won’t look in the inc directory for the header. You need to tell it to look there somehow.

One thing some people try when faced with this problem is to re-write myfile.cpp so it looks like this:

#include "c:/myprojects/aproject/inc/myheader.h"

or the slightly more sophisticated:

#include "../inc/myheader.h"

Both of these are a bad idea, as they tie your C++ code to the project’s directory structure and/or location, both of which you will probably want to change at some point in the future. If the directory structure does change, you will have to edit all your #include directories.The better way to deal with this problem is to tell the compiler directly where to look for header files. You can do that with the compiler’s -I option, which tells the compiler to look in the specified directory, as well as the ones it normally searches:

g++ -Ic:/myprojects/aproject/inc myfile.cpp

Now the original #include directive:

#include "myheader.h"

will work, and if your directory structure changes you need only modify the compiler command line. Of course, writing such command lines is error prone, and you should put such stuff in a makefile, the use of which is unfortunately outside the scope of this article.

Problems with libraries

Somewhat similar issues to those described above can occur when you want to use a third-party library.  Suppose you want to use the excellent random number generating facilities of the Boost library. If you are copying example code, you may well end up with something like this in your C++ source file:

#include "boost/random.hpp"

This will in all probability lead to yet another «No such file or directory» message, as once again the compiler does not know where «boost/random.hpp» is supposed to be. In fact, it is one of the subdirectories of the Boost installation, and on my system I can get the #include directive to work using this command line:

g++ -Ic:/prog/boost1461 myfile.cpp

where /prog/boost1461 is the root directory for my specific Boost library installation.

Can’t find C++ Standard Library files?

One last problem that beginners run into is the inability of the compiler to find header files that are part of the C++ Standard Library. One particular favourite is this one:

#include <iostream.h>

where you are learning C++ from a very, very old book. Modern C++ implementations have not contained a file called iostream.h for a very long time indeed, and your compiler is never going to find it. You need to use the correct, standard names for such headers (and to get a better book!):

#include <iostream>

If this still fails, then there is almost certainly something very wrong with your GCC installation. The GCC compiler looks for Standard Library files in a subdirectory of its installation, and locates that directory relative to the directory containing the compiler executable, so if the Standard Library headers are available, the compiler should always find them.

Conclusion

This article looked at the «No such file or directory»  message of the GCC C++ compiler.  If you get this message you should:

• Remember that the compiler is always right in situations like this.
• Look very closely at the file name to make sure it is correct.
• Avoid naming file using mixed-case or special characters.
• Use the -I compiler option to tell the compiler where to look for files.
• Make sure that GCC is correctly installed on your system.

fatal error C1083: Cannot open include file: ‘windows.h’: No such file or directory

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Ошибка fatal error C1083: Cannot open include file: ***: No such file or directory
Помогите пожалуйста исправить ошибку. При компиляции возникает вот такая беда. подробности в.

Fatal error C1083: Не удается открыть файл include: iostream.h: No such file or directory
Ругается и все, Подскажите,что делать? Ошибка 1 fatal error C1083: Не удается открыть файл.

наскоко мне память не изменяет Visul C++ 2005 Express Editional это не полная версия просто в ней отсутствует инклуд windows.h

Добавлено через 2 минуты
для полной разработки приложений тебе надо Visul C++ 2005 Profissional Editional

Fatal error C1083: Не удается открыть файл include: afxwin.h: No such file or directory
Помогите установить VC++ 2008. Что делать при этой ошибке: Ошибка 1 fatal error C1083: Не удается.

Ошибка «Fatal error C1083: Не удается открыть файл include: stdafx.h: No such file or directory»
Здравствуйте, помогите пожалуйста во многих лабораторных работах выдаёт ошибку «fatal error C1083.

Источник

windows.h no such file or directory (compile c code on linux) [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

main.c:2:10: fatal error windows.h: No such file or directory compilation terminated

Do you have any idea why this error happens and how to fix?

1 Answer 1

The problem is that your code is using the windows.h header file to get function declarations for Windows-only functions. This file does not normally exist on Linux, because its installations of toolchains (such as GCC) will (by default) only include the files needed to compile for Linux.

You have a few options:

As Ed Heal suggested, port the code to Linux. That means you would remove the inclusion of windows.h, and replace all the function calls that used the Windows API with their Linux equivalents. This will make your source code only work on Linux, unless you can refactor the OS-dependent calls into platform-agnostic code. A word of warning: unless the program you’re working with is trivial, this is not an easy task. There’s no guarantee that every Windows API function has a Linux equivalent.

Install a Windows toolchain for your build system, which should include windows.h, and cross-compile your code. This will result in a binary that won’t work on Linux, but will work on Windows.

A middle ground between those two options would be to actually do both, and use conditional compilation to allow you to selectively compile for one target or another.

Источник

«Cannot open include file: ‘config-win.h’: No such file or directory» while installing mysql-python

I’m trying to install mysql-python in a virtualenv using pip on windows. At first, I was getting the same error reported here, but the answer there worked for me too. Now I’m getting this following error:

If I symlink (Win7) to my regular (not the virtualenv’s) python’s site-packages/MySQLdb dir I get

I’m rather at a loss here. Any pointers?

22 Answers 22

All I had to do was go over to oracle, and download the MySQL Connector C 6.0.2 (newer doesn’t work!) and do the typical install.

Be sure to include all optional extras (Extra Binaries) via the custom install, without these it did not work for the win64.msi

Once that was done, I went into pycharms, and selected the MySQL-python>=1.2.4 package to install, and it worked great. No need to update any configuration or anything like that. This was the simplest version for me to work through.

The accepted solution no longer seems to work for newer versions of mysql-python. The installer no longer provides a site.cfg file to edit.

Update for mysql 5.5 and config-win.h not visible issue

In 5.5 config-win. has actually moved to Connector separate folder in windows. i.e. smth like:

C:Program FilesMySQLConnector C 6.0.2include

To overcome the problem one need not only to download «dev bits» (which actually connects the connector) but also to modify mysqldb install scripts to add the include folder. I’ve done a quick dirty fix as that.

in setup_windows.py locate the line

Ugly but works until mysqldb authors will change the behaviour.

Almost forgot to mention. In the same manner one needs to add similar additional entry for libs:

i.e. your setup_windows.py looks pretty much like:

The accepted answer is out of date. Some of the suggestions were already incorporated in the package, and I was still getting the error about missing config-win.h & mysqlclient.lib.

pip install mysql-python

P.S. Since I don’t use MySQL anymore, my answer may be out of date as well.

I know this post is super old, but it is still coming up as the top hit in google so I will add some more info to this issue.

I was having the same problems as OP but none of the suggested answers seemed to work for me. Mainly because «config-win.h» didn’t exist anywhere in the connector install folder.

I was using the latest Connector C 6.1.6 as that was what was suggested by the MySQL installer.

This however doesn’t seem to be supported by the latest MySQL-python package (1.2.5). When trying to install it I could see that it was explicitly looking for C Connector 6.0.2.

Источник

Thread: windows.h no such file or directory

Thread Tools

Search Thread

Display

windows.h no such file or directory

I am working on getting a new compiler and the one im looking at is MVC(not sure if the ++ are included on the end lol). Anyways, my current compiler is Dev 4.9.2 and it compiles and runs my program just fine. But when I moved the code over to the MVC and tried it, it didnt work. I got the same error multiple times. So then I downloaded Platform SDK and added in the lib,bin and include files I was supposed to. I also changed a line of code that had kerbel.lib or something like that on it(which I was supposed to do). And I still cant get it to work.

here is the error message:

This is how I used it in the actual code:

I tried changing windows.h to windows and that didnt work either. So im nnot really sure wat else to do. If someone could explain to me why it doesnt work and/or how to fix it that would be great.

I didn’t see step 5 the first time through(I was in a hurry and didnt scroll down that far). Anyways, I commented out the for lines that it says t comment out. Then it says:

I did exactly what it said but cant finish it because I cant make a windows app. And I have no idea why I cant.

If you were in a hurry then, double check now if you have the needed paths on the include list.

Well, I’m glad you said that mario. I did add the paths I was supposed to add, but I added all 3 of them into the executables. I fixed that part. But I still got the error when I ran my program, and I still cant make a windows app. I still can only make a console app.

I also just noticed another thing. On the page Ancient Dragon pointed out says to comment out lines 441-444

in C:Program FilesMicrosoft Visual Studio 8VCVCWizardsAppWizGenericApplicationhtml103 3. I went there, opened the file in Notepad(it mentioned opening it in a text editor) and looked for the 4 lines. Well, I only found these 3 lines.

So, should I just replace the 3 lines I have with the 4 lines it says should be commented out. Or could this really screw up the program?

EDIT: Ok cool. I found the 4 lines. I didnt notice them the first few searches. But I just found them and commented them out. Its working a’ok now.

RE-EDIT!: Bah! Ok, I thought it was working but unfortunately it isnt. I can now make windows apps and dll’s. Yet it still says that there is no winows.h. I just dont get it, ive done all the install steps. All the other headers work just fine. I dont know what else to do from here. It works just fine in Dev C++. Is there some stupidly obvious lib im supposed to add or something?

Источник