Hi !
I'm new user of Code::Blocks and i started with avr-gcc project.
My project compile fine in command line (not with Code::Blocks) with my custom Makefile.
I've trying to copy out this Makefile in Code::Blocks but when i compile, i've this error :
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
I've trying with my custom Makefile (By checking « This is a custom Makefile » in Project properties) but i've the same error.
I think that installing the package "glibc-devel.i686" can solve the problem but why Code: Blocks would need this package which compile fine in command line ?
Thanks
Should your project normally need it?
If yes, check directories.
Else, if you check "use a custom makefile" in C::B's project, do it work?
If yes, there is a problem with the configuration of your project.
I think you can look near included libs, maybe the assistant insert "gnu/stubs-32.h" ?
Quote from: Freem on August 10, 2011, 02:46:23 PM
Should your project normally need it?
If yes, check directories.
No, because it works outside Code::Blocks
With my custom Makefile, it don't need stubs-64.h either (So my project don't need stubs.h ...)
(I've tried to rename stubs-64.h to stubs-64.h.old and to compile with custom Makefile and it works)
Quote from: Freem on August 10, 2011, 02:46:23 PM
Else, if you check "use a custom makefile" in C::B's project, do it work?
Yes
Quote from: Freem on August 10, 2011, 02:46:23 PM
If yes, there is a problem with the configuration of your project.
I think you can look near included libs, maybe the assistant insert "gnu/stubs-32.h" ?
Here (http://paste.tuxfamily.org/71732acf15.html) is the cbp file of my project, you can see it have no mention of any stubs header
Read this: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F and enable full logging.
Then inspect the commands and try them in a terminal to see, which flag or option causes this behaviour.
Ok, it works when I remove the « /usr/include » path in Global Compiler Settings -> GNU AVR GCC Compiler -> Search Directories -> Compiler.
This path wasn't added by me, it's the default config.
Is this path useful for anything ?
It's not in the default config of C::B !
I don't have it in my clean "GNU AVR GCC Compiler" settings.
So removing it should be save.
Quote from: jens on August 10, 2011, 04:22:53 PM
It's not in the default config of C::B !
I don't have it in my clean "GNU AVR GCC Compiler" settings.
So removing it should be save.
I confirm is it the default config of Code::Blocks. At least on Fedora 15 and x86_64.
I just to test on another machine with a fresh install of this distribution.
Maybe a « wrong » rpm package ...
I don't have it in the defaults. (self compiled on centos)
Could you check if you avr-project-wizard is not doing it wrong?
Quote from: oBFusCATed on August 10, 2011, 09:05:45 PM
Could you check if you avr-project-wizard is not doing it wrong?
How ?
Choose the wizard -> right click -> edit script
Quote from: oBFusCATed on August 10, 2011, 09:19:43 PM
Choose the wizard -> right click -> edit script
I've seen nothing strange here.
But, here (http://paste.tuxfamily.org/5e3880278b.html), you can see my ~/.codeblocks/default.conf file.
See at lines 728-732.
Quote from: Difool on August 10, 2011, 09:32:55 PM
Quote from: oBFusCATed on August 10, 2011, 09:19:43 PM
Choose the wizard -> right click -> edit script
I've seen nothing strange here.
But, here (http://paste.tuxfamily.org/5e3880278b.html), you can see my ~/.codeblocks/default.conf file.
See at lines 728-732.
Please close C::B and rename the
default.conf.
Than restart C::B, so the configuration is rebuild from scratch and check the "Search directories".
Quote from: jens on August 10, 2011, 09:50:05 PM
Please close C::B and rename the default.conf.
Than restart C::B, so the configuration is rebuild from scratch and check the "Search directories".
/usr/include always appear in the search directory
I've just to test on another linux distribution (Ubuntu 11.04 x86_64).
And it's have the same problem : the /usr/include path is, by default, in the « Search Directory » for the AVR GCC Compiler.
So the problem is not with Fedora package but with Code::Block default settings
What happens, when you:
1. stop codeblocks
2. delete ~/.codeblocks/default.conf
3. start codeblocks
Do you see the same problem?
Seems the autodetection fails, see for the details: CompilerGNUAVR::AutoDetectInstallationDir()
http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compilerGNUAVR.cpp?peg=7359
Seems like the m_MasterPath is not set correctly.
Quote from: Difool on August 10, 2011, 10:03:30 PM
Quote from: jens on August 10, 2011, 09:50:05 PM
Please close C::B and rename the default.conf.
Than restart C::B, so the configuration is rebuild from scratch and check the "Search directories".
/usr/include always appear in the search directory
I've already do this ...
And I said I had tested with two differents linux distribs (Fedora & Ubuntu), both are fresh installs (in fact, with Live CD ...).
So, they haven't ~/.codeblocks/default.conf
Quote from: oBFusCATed on August 11, 2011, 03:10:18 PM
Seems the autodetection fails, see for the details: CompilerGNUAVR::AutoDetectInstallationDir()
http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compilerGNUAVR.cpp?peg=7359
Seems like the m_MasterPath is not set correctly.
m_MasterPath is set by :
if (platform::windows)
{
....
}
else // if platform::linux
m_MasterPath = _T("/usr");
But what is the usefulness of adding this include path ?
AddIncludeDir(m_MasterPath + sep + _T("include"));
After installing avr-gcc, I cam confirm this issue.
If the compiler-plugin detects the gnu-avr-gcc compiler it adds /usr/include and /usr/lib to the appropriate search dirs, but this is (of course) wrong for a cross-compiler.
I guess none of these is normally needed as long as only compiler-included headers and libs are used, because the compiler normally knows where to search.
I am not sure if it is needed on windows, normally it should not.
The wrong search-dirs are only added, if auto-detection does not fail:
AutoDetectResult ret = wxFileExists(m_MasterPath + sep + _T("bin") + sep + m_Programs.C) ? adrDetected : adrGuessed;
if (ret == adrDetected)
{
if (platform::windows)
{
AddIncludeDir(m_MasterPath + sep + _T("avr\\include"));
AddLibDir(m_MasterPath + sep + _T("avr\\lib"));
m_ExtraPaths.Add(m_MasterPath + sep + _T("utils") + sep + _T("bin")); // for make
}
else
{
AddIncludeDir(m_MasterPath + sep + _T("include"));
AddLibDir(m_MasterPath + sep + _T("lib"));
}
}
m_MasterPath is /usr, because the executables are in /usr/bin as nearly in all cases on linux.
That's the cause, why I did not see them until I installed the compiler.
Quote from: Difool on August 11, 2011, 03:18:08 PM
Quote from: oBFusCATed on August 11, 2011, 03:10:18 PM
Seems the autodetection fails, see for the details: CompilerGNUAVR::AutoDetectInstallationDir()
http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compilerGNUAVR.cpp?peg=7359
Seems like the m_MasterPath is not set correctly.
m_MasterPath is set by :
if (platform::windows)
{
....
}
else // if platform::linux
m_MasterPath = _T("/usr");
But what is the usefulness of adding this include path ?
AddIncludeDir(m_MasterPath + sep + _T("include"));
As posted before: master path is set correctly, but the search-dirs are not (and most likely not needed).
Yes, so the AutoDetectInstallationDir() function seems to be useless and even undesirable. (It remains to be confirmed for Windows).
Should I open a ticket on the bugtracker (http://developer.berlios.de/bugs/?group_id=5358) for this ?