Here is my problem: I've installed Dev C++ recently and had a go at compiling the smallest of programs (in fact what you get when you create a new C project).
It looks like that:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
system("PAUSE");
return 0;
}
Unfortunately, i get the following log when i try to compile it:
Compiler: Default compiler
Building Makefile: "D:\Documents and Settings\Admin\Bureau\Nouveau dossier\Makefile.win"
Executing make...
make.exe -f "D:\Documents and Settings\Admin\Bureau\Nouveau dossier\Makefile.win" all
gcc.exe -c main.c -o main.o -I"D:/Dev-Cpp/include"
/mingw/lib/crt2.o(.text+0x167):crt1.c: undefined reference to `__cpu_features_init'
collect2: ld returned 1 exit status
make.exe: *** [Project1.exe] Error 1
Execution terminated
So i've looked up in this forum and found a similar case where the user had to use another windows account, with a logon exempt from special turquese characters. Although it is not the case here, i thought maybe my Windows install was at fault, being installed on the D: partition.
I've restarted the computer and started another Windows install on C: (that i rarely use, D: being my default workplace). Surprise ! Everything went fine there...
Does DevC++ have trouble with a non-standard windows XP install (I mean not on C:) ?
I use Win XP Pro 32 bits and installed the whole DevC++ package with mingw.
Of course i could just use the other XP when i learn programming, but i like when problems are solved...
On D: (where it doesn't work) i have a standalone install on mingw as well, directly under the root. Its path has been added in the variable paths. Could it be the reason ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Error 1" is emitted from the make utility - it is not the actual error, it merely means that the build failed. That could be for any number of reasons, and this is not related at all to the Turkish character case.
You have to read error logs from the top down, not the bottom up!
I once installed Dev-C++ on drive D:, there is no reason why it should not work, but some DevPaks installed without taking into account the installation location and had references to C:\Dev-Cpp in their project templates, so to avoid problems, it is probably best left in the default location. Of course I could have modified the templates. However this is not your problem in this case either.
One possible cause is your use of project paths containing spaces ("D:\Documents and Settings\Admin\Bureau\Nouveau dossier"). The "PLEASE READ BEFORE POSTING A QUESTION" thread explicitly warns about that, so you have no excuse! The GNU tools are ported from Linux, and not all of the components deal correctly with paths with spaces all of the time. Sometimes it seems to work, and others it does not, but it will always get you in teh end if you do it every time. Best avoided.
Even if the spaces in the path are not the cause of the problem you should fix that before proceeding - always remove teh problem you can see before looking for the ones you cannot.
Searching the forum or even Google for the error message is another good practice. However, as I said you havce to be able to see the real error message! In this case "undefined reference to `__cpu_features_init'", one hit you might then find is http://sourceforge.net/forum/forum.php?thread_id=1637599&forum_id=48211 where the cause was the existence of more than one GNU tool-chain.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> On D: (where it doesn't work) i have a standalone install on
> mingw as well, directly under the root. Its path has been
> added in the variable paths. Could it be the reason ?
Oops, I missed that - yes that is the reason!
Use the IDE-only version of Dev-C++ and configure it to use your existing installation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your very quick answer.
I didn't give much importance to this spaces problem because the install on C (the working one) uses the same paths with spaces in the names and doesn't fail.
I have a very bad overview of what does what in this compiler/linker business : i am an absolute beginner (apart from some python scripting) and didn't even know how to read the log !
Sorry if i give the impression that i didn't search properly before posting, but i have spent a few hours on the web trying to understand and nothing seemed to fit
Thanks !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello !
Here is my problem: I've installed Dev C++ recently and had a go at compiling the smallest of programs (in fact what you get when you create a new C project).
It looks like that:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
}
Unfortunately, i get the following log when i try to compile it:
Compiler: Default compiler
Building Makefile: "D:\Documents and Settings\Admin\Bureau\Nouveau dossier\Makefile.win"
Executing make...
make.exe -f "D:\Documents and Settings\Admin\Bureau\Nouveau dossier\Makefile.win" all
gcc.exe -c main.c -o main.o -I"D:/Dev-Cpp/include"
gcc.exe main.o -o "Project1.exe" -L"D:/Dev-Cpp/lib"
/mingw/lib/crt2.o(.text+0x167):crt1.c: undefined reference to `__cpu_features_init'
collect2: ld returned 1 exit status
make.exe: *** [Project1.exe] Error 1
Execution terminated
So i've looked up in this forum and found a similar case where the user had to use another windows account, with a logon exempt from special turquese characters. Although it is not the case here, i thought maybe my Windows install was at fault, being installed on the D: partition.
I've restarted the computer and started another Windows install on C: (that i rarely use, D: being my default workplace). Surprise ! Everything went fine there...
Does DevC++ have trouble with a non-standard windows XP install (I mean not on C:) ?
I use Win XP Pro 32 bits and installed the whole DevC++ package with mingw.
Of course i could just use the other XP when i learn programming, but i like when problems are solved...
On D: (where it doesn't work) i have a standalone install on mingw as well, directly under the root. Its path has been added in the variable paths. Could it be the reason ?
Hi again !
I did what you said about the version of DevC++without mingw and (as expected) it works fine !
Thanks for your support !
"Error 1" is emitted from the make utility - it is not the actual error, it merely means that the build failed. That could be for any number of reasons, and this is not related at all to the Turkish character case.
You have to read error logs from the top down, not the bottom up!
I once installed Dev-C++ on drive D:, there is no reason why it should not work, but some DevPaks installed without taking into account the installation location and had references to C:\Dev-Cpp in their project templates, so to avoid problems, it is probably best left in the default location. Of course I could have modified the templates. However this is not your problem in this case either.
One possible cause is your use of project paths containing spaces ("D:\Documents and Settings\Admin\Bureau\Nouveau dossier"). The "PLEASE READ BEFORE POSTING A QUESTION" thread explicitly warns about that, so you have no excuse! The GNU tools are ported from Linux, and not all of the components deal correctly with paths with spaces all of the time. Sometimes it seems to work, and others it does not, but it will always get you in teh end if you do it every time. Best avoided.
Even if the spaces in the path are not the cause of the problem you should fix that before proceeding - always remove teh problem you can see before looking for the ones you cannot.
Searching the forum or even Google for the error message is another good practice. However, as I said you havce to be able to see the real error message! In this case "undefined reference to `__cpu_features_init'", one hit you might then find is http://sourceforge.net/forum/forum.php?thread_id=1637599&forum_id=48211 where the cause was the existence of more than one GNU tool-chain.
Clifford
> On D: (where it doesn't work) i have a standalone install on
> mingw as well, directly under the root. Its path has been
> added in the variable paths. Could it be the reason ?
Oops, I missed that - yes that is the reason!
Use the IDE-only version of Dev-C++ and configure it to use your existing installation.
Hi Clifford !
Thank you for your very quick answer.
I didn't give much importance to this spaces problem because the install on C (the working one) uses the same paths with spaces in the names and doesn't fail.
I have a very bad overview of what does what in this compiler/linker business : i am an absolute beginner (apart from some python scripting) and didn't even know how to read the log !
Sorry if i give the impression that i didn't search properly before posting, but i have spent a few hours on the web trying to understand and nothing seemed to fit
Thanks !