Code::Blocks Forums
User forums => Help => Topic started by: NameZero912 on April 19, 2007, 07:15:36 pm
-
Ok I got this problem:
I created a very easy C++ sample project where I define a function in one cpp file and also created a funcname.h file that declares the function so it can be used by other functions in other files. All cpp and h files are created using File->New->File and selecting the Source/header icon and creating it with that Wizard. When creating the header file I added it to the projects debug and release target, and it seems to be properly integrated in the project.
Anyway, when I want to compile it (doesn't matter if debug or release) it refuses to do so and gives this message:
....main.cpp:3: funcname.h: No such file or directory
:: === Build finished: 1 errors, 0 warnings ===
This are the system specifications:
- Win XP SP2
- Codeblock SVN Revision 3865
- MinGW 5.1.3 installer that installed the "Current" GCC.
Any ideas ?
Another thing that I was wondering about: CB wouldn't recognize the MinGW compiler by default. I had to setup the compiler path manually (in the "Toolchain executables" dialog).
-
Anyway, when I want to compile it (doesn't matter if debug or release) it refuses to do so and gives this message:
....main.cpp:3: funcname.h: No such file or directory
:: === Build finished: 1 errors, 0 warnings ===
Please enable full command-line logging (Settings->Compiler and debugger->Global compiler settings->Other settings->Compiler logging), and post the entire output of the build log.
If funcname.h is not in the same directory as the file that includes it, or if your project uses the "Generate PCH in the object output dir" strategy (in the Project settings section of your project's Properties dialog), you will need to explicitly add the directory that contains funcname.h to your project's include paths (Project->Build options->Search directories->Compiler).
Another thing that I was wondering about: CB wouldn't recognize the MinGW compiler by default. I had to setup the compiler path manually (in the "Toolchain executables" dialog).
Code::Blocks can currently only auto-detect MinGW if it is installed in the root of the main drive; i.e. C:\MinGW. All other locations require the path to be set manually as you have done.
-
Ok. I enabled full logging, cleaned the project (right click on project and selected "Clean") and tried to build it again.
This comes up in the build log (not really any more information about the issue tbh):
-------------- Build: Debug in Aufgabe 2.8 ---------------
mingw32-g++.exe -Wall -fexceptions -g -ID:\Programme\MinGW\include -c "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\printbits.cpp" -o obj\Debug\printbits.o
D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\printbits.cpp:1:23: printbits.h: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
As you can see, I setup the MinGW patch to "D:\Programme\MinGW". The project consists of main.cpp, printbits.cpp and printbits.h
Content of main.cpp:
#include <iostream>
#include <printbits.h>
using namespace std;
int main()
{
int zahl = -5;
cout << "Teste Funktion printbits mit " << zahl << " -> Binaermuster: " << printbits(zahl) << endl;
return 0;
}
Content of printbits.cpp:
include <printbits.h>
char* printbits(int zahl) {
//implementation of function
}
Content of printbits.h:
#ifndef PRINTBITS_H_INCLUDED
#define PRINTBITS_H_INCLUDED
extern char* printbits(int zahl);
#endif
The project uses the default setting for that PCH thing btw. And the .h file does exist in the same directory as the .cpp file!
Any ideas what's wrong there?
-
Try changing that
#include <printbits.h>
to be
#include "printbits.h"
The angle brackets <> tell the compiler to look in the standard
(built-in) include directories, not your own source directory.
-- Ringo
-
What Ringo said. :)
-
Thanks for that hint. However, I'm getting another error now:
-------------- Build: Debug in Aufgabe 2.8 ---------------
mingw32-g++.exe -Wall -fexceptions -g -ID:\Programme\MinGW\include -c "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\printbits.cpp" -o obj\Debug\printbits.o
mingw32-g++.exe -Wall -fexceptions -g -ID:\Programme\MinGW\include -c "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -L"D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\" -LD:\Programme\MinGW\lib -o "bin\Debug\Aufgabe 2.8.exe" obj\Debug\printbits.o printbits.h.gch obj\Debug\main.o
mingw32-g++.exe: 2.8.exe obj\Debug\printbits.o printbits.h.gch obj\Debug\main.o: No such file or directory
mingw32-g++.exe: no input files
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
What can I do about this ? the PCH setting is the default one. I tried adding some paths to the projects Debug/Release settings but it didn't help either.
And btw, is it normal that the printbits.h file appears in a grey color (compared to the cpp sources that appear in black color) ?
-
And btw, is it normal that the printbits.h file appears in a grey color (compared to the cpp sources that appear in black color) ?
No. It appears you have printbits.h set to be linked in its file properties, which will never be correct for header files. Right click the file, select Properties, find the Compile file and Link file options, and make sure both are unchecked.
-
Ok. I unchecked the "Link" checkbox at the place you mentioned. When compiling the project the error is different now. However, the header files does STILL BE GREY, just fyi. So it's either a C::B bug or something different.
The error that is coming now ... well ... is an error that claims that it cannot find files which DO BE there in the right directories:
-------------- Build: Debug in Aufgabe 2.8 ---------------
mingw32-g++.exe -Wall -fexceptions -g -ID:\Programme\MinGW\include -c "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\printbits.cpp" -o obj\Debug\printbits.o
mingw32-g++.exe -Wall -fexceptions -g -ID:\Programme\MinGW\include -c "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -L"D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\" -LD:\Programme\MinGW\lib -o "bin\Debug\Aufgabe 2.8.exe" obj\Debug\printbits.o obj\Debug\main.o
mingw32-g++.exe: 2.8.exe obj\Debug\printbits.o obj\Debug\main.o: No such file or directory
mingw32-g++.exe: no input files
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
When looking into "D:\Daten\FH\Info2 Practices Codeblock Projects\Aufgabe 2.8\obj\Debug\" I can see main.o and printbits.o, obviously the compiler claims, not to be able to find the files he just compiled (which I think, is funny :D)
When I had a closer look I found out that this line
mingw32-g++.exe: 2.8.exe obj\Debug\printbits.o obj\Debug\main.o: No such file or directory
discovered that the "Aufgabe " was just cut off
--> I created a new project called "Aufgabe2.8" (previous project name was "Aufgabe 2.8", note the blank between 'Aufgabe' and '2.8'). After that, it worked!
So does this generally mean projects may not have spaces in its name when the built binary would then have spaces too ? And how can I change the name of the binary ?
-
However, the header files does STILL BE GREY, just fyi. So it's either a C::B bug or something different.
A very small C::B bug; reload the project and it will be gone.
So does this generally mean projects may not have spaces in its name when the built binary would then have spaces too ? And how can I change the name of the binary ?
It should be fine for the project name and file to have spaces in them. You can change the name of the output executable in the build target properties.
-
A very small C::B bug; reload the project and it will be gone.
Thats odd, because in the meanwhile I restarted Codeblocks a couple of times (and thus reopened the same project as well) and the header file remains grey (when it is not clicked).
It should be fine for the project name and file to have spaces in them. You can change the name of the output executable in the build target properties.
Thanks for that info.
-
Thats odd, because in the meanwhile I restarted Codeblocks a couple of times (and thus reopened the same project as well) and the header file remains grey (when it is not clicked).
Then either you have not made sure that both the Compile and Link options for that file were unchecked, or the bug is more pronounced than I thought.
-
Thats odd, because in the meanwhile I restarted Codeblocks a couple of times (and thus reopened the same project as well) and the header file remains grey (when it is not clicked).
Then either you have not made sure that both the Compile and Link options for that file were unchecked, or the bug is more pronounced than I thought.
Any non-compilable files are displayed in gray. This is normal behaviour.
-
Any non-compilable files are displayed in gray. This is normal behaviour.
This is true; I think I misinterpreted the original concern to mean that the header in question was different from the rest of the headers. My apologies.