User forums > Nightly builds
The 16 September 2014 build (9916) is out.
danselmi:
--- Quote from: scarphin on October 06, 2014, 09:32:32 am ---Good to hear that as embedded compilers not in system path might result in the same error.
--- End quote ---
I have seen this problem with embedded compilers too.
Discussed (internally) here:
http://forums.codeblocks.org/index.php/topic,19377.msg132453.html#msg132453
White-Tiger:
I had mentioned that CC problem within my post scriptum as well: http://forums.codeblocks.org/index.php/topic,19695.msg134492.html#msg134492
Though the problem is my 64bit GCC as my 32bit GCC is in my path. I thought the problem was that the 64bit GCC tries to use 32bit DLLs xD But if CC doesn't even set the path, it makes sense^^
P.S. that link of yours is really "internal" danselmi^^ No access for others :P
ollydbg:
Yeah, it looks like CC don't set the PATH environment to run the gcc or g++ command.
The related code:
--- Code: ---void NativeParser::AddGCCCompilerDirs(const wxString& masterPath, const wxString& compilerCpp, ParserBase* parser)
{
wxFileName fn(wxEmptyString, compilerCpp);
wxString masterPathNoMacros(masterPath);
Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPathNoMacros);
fn.SetPath(masterPathNoMacros);
fn.AppendDir(_T("bin"));
const wxArrayString& gccDirs = GetGCCCompilerDirs(fn.GetFullPath());
TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding %lu cached gcc dirs to parser..."), static_cast<unsigned long>(gccDirs.GetCount()));
for (size_t i=0; i<gccDirs.GetCount(); ++i)
{
parser->AddIncludeDir(gccDirs[i]);
TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding cached compiler dir to parser: ") + gccDirs[i]);
}
}
--- End code ---
Run the command to fetch the GCC's include paths.
--- Code: ---// These dirs are the built-in search dirs of the compiler itself (GCC).
// Such as when you install your MinGW GCC in E:/code/MinGW/bin
// The buildin search dir may contains: E:/code/MinGW/include
const wxArrayString& NativeParser::GetGCCCompilerDirs(const wxString &cpp_compiler)
{
// keep the gcc compiler path's once if found across C::B session
// makes opening workspaces a *lot* faster by avoiding endless calls to the compiler
static std::map<wxString, wxArrayString> dirs;
if (!dirs[cpp_compiler].IsEmpty())
return dirs[cpp_compiler];
// wxExecute can be a long action and C::B might have been shutdown in the meantime...
// This is here, to protect at re-entry:
if (Manager::IsAppShuttingDown())
return dirs[cpp_compiler];
TRACE(_T("NativeParser::GetGCCCompilerDirs(): Enter"));
// for starters , only do this for gnu compiler
//CCLogger::Get()->DebugLog(_T("CompilerID ") + CompilerID);
//
// Windows: mingw32-g++ -v -E -x c++ nul
// Linux : g++ -v -E -x c++ /dev/null
// do the trick only for c++, not needed then for C (since this is a subset of C++)
// let's construct the command
// use a null file handler
// both works fine in Windows and Linux
wxString Command(cpp_compiler + _T(" -v -E -x c++ /dev/null"));
if (platform::windows)
Command = cpp_compiler + _T(" -v -E -x c++ nul"); // on Windows, its different
static bool flag = false;
if (flag)
return dirs[cpp_compiler];
// action time (everything shows up on the error stream
wxArrayString Output, Errors;
flag = true;
if ( wxExecute(Command, Output, Errors, wxEXEC_SYNC | wxEXEC_NODISABLE) == -1 )
{
TRACE(_T("NativeParser::GetGCCCompilerDirs(): GetGCCCompilerDirs::wxExecute failed!"));
flag = false;
return dirs[cpp_compiler];
}
flag = false;
// wxExecute can be a long action and C::B might have been shutdown in the meantime...
// This is here, to protect a long run:
if ( Manager::IsAppShuttingDown() )
return dirs[cpp_compiler];
// start from "#include <...>", and the path followed
// let's hope this does not change too quickly, otherwise we need
// to adjust our search code (for several versions ...)
bool start = false;
for (size_t idxCount = 0; idxCount < Errors.GetCount(); ++idxCount)
{
wxString path = Errors[idxCount].Trim(true).Trim(false);
if (!start)
{
if (!path.StartsWith(_T("#include <...>")))
continue;
path = Errors[++idxCount].Trim(true).Trim(false);
start = true;
}
wxFileName fname(path, wxEmptyString);
fname.Normalize();
fname.SetVolume(fname.GetVolume().MakeUpper());
if (!fname.DirExists())
break;
dirs[cpp_compiler].Add(fname.GetPath());
CCLogger::Get()->DebugLog(_T("NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: ") + fname.GetPath());
}
TRACE(_T("NativeParser::GetGCCCompilerDirs(): Leave"));
return dirs[cpp_compiler];
}
--- End code ---
ollydbg:
--- Quote from: danselmi on October 06, 2014, 08:27:41 am ---This is a bug in CC plugin.
The compiler plugin is able to call the compiler correctly.
--- End quote ---
Think it more.
If I remember correctly, in compiler plugin, when it want to call the g++.exe. (suppose it is under D:/mingw32/bin/g++.exe), the compiler just add the path "D:/mingw32/bin" to the environment variable PATH as the first place search path. After finish compiling, it just remove the first search path from PATH variable.
Do we need to such things in CC? Should Compiler plugin supply an API to do this?
White-Tiger:
I think a better way would be to set the path once so it's used everywhere^^
Just update the path and other settings when the target changes... Though this doesn't work out of the box with virtual targets because they could contain more then one compiler (from different real targets)
Generally the virtual target stuff need a rewrite :P Maybe switch on compile time to each and every real target (ignoring the first as it should already be set, so the first real target of a virtual target is internally selected, after compiling that, select to the other ones and finally revert back the the first)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version