User forums > Nightly builds
The 02 November 2012 build (8500) is out.
march1993:
--- Quote from: march1993 on November 03, 2012, 02:53:31 am ---
--- Quote from: MortenMacFly on November 02, 2012, 04:31:33 pm ---
--- Quote from: march1993 on November 02, 2012, 03:22:59 pm ---It seems that code completion doesn’t work properly with SDCC 3.2.0.
--- End quote ---
What do you think shall we make out of this sentence, please? What does when not work with what versions - details, steps to reproduce etc... please.
--- End quote ---
install SDCC 3.2.0 and code::blocks 8500, then create a default MCS51 project, open main.c, input "INT", the code completion should pop up with "INT0" or "INT1". but code::blocks does nothing.
--- End quote ---
It seems that code::blocks works properly with an older version of SDCC.
ollydbg:
I see a wired bug, When I try to use this nightly build version to build the cb, I have such build error:
--- Code: ----------------- Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: AutoRevision in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: ConsoleRunner in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: Squirrel in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: Squirrel std lib in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: SqPlus in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: scintilla in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: wxpropgrid in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
[100.0%] Running target pre-build steps
build_tools/autorevision/autorevision +wx +int +t . include/autorevision.h
'svn' is not recognized as an internal or external command,
operable program or batch file.
'git' is not recognized as an internal or external command,
operable program or batch file.
'svn' is not recognized as an internal or external command,
operable program or batch file.
-------------- Build: sdk in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
[ 33.3%] Running target post-build steps
[ 66.7%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
cmd /c "cd sdk\resources & zip -0 -q ..\..\devel\share\CodeBlocks\manager_resources.zip images\*.png images\12x12\*.png images\16x16\*.png"
'zip' is not recognized as an internal or external command,
operable program or batch file.
Process terminated with status 1 (0 minutes, 4 seconds)
0 errors, 0 warnings (0 minutes, 4 seconds)
--- End code ---
But I have "zip" and "svn" command in my PATH, see the log:
--- Code: ---
C:\>which svn
C:\Program Files\SlikSvn\bin\svn.EXE
C:\>which zip
E:\code\common_bin\zip.EXE
C:\>
--- End code ---
So, I suspect the PATH variable was sometimes changed by compiler plugin? I will check an old nightly build version.
ollydbg:
The bad thing is: if I rebuild C::B, I will sometimes see the warning message(see below)
Does this mean that my "PATH" was locked by some one/software?
ollydbg:
It looks like in my system, wxSetEnv failed.
See a related discussion: Re: C::B execution paths
--- Quote ---In a private project of mine I had the issue that wxSetEnv is unreliable for some reason. So what I did was the following:
Code:
bool mySetEnv(const wxString& name, const wxString& value)
{
// The WX-way...
bool success = wxSetEnv(name, value);
// The MinGW-way...
wxString putenv_var = name + wxT("=") + value;
#if wxUSE_UNICODE
std::string stl_putenv_var = (const char*)putenv_var.mb_str(wxConvLocal);
#else
std::string stl_putenv_var = putenv_var.c_str();
#endif
char buffer[stl_putenv_var.length()+1]; memset(buffer, 0x00, sizeof(buffer));
memcpy(buffer, stl_putenv_var.c_str(), stl_putenv_var.length());
success &= ( putenv(buffer)==0 ); // returns 0 on success
// success &= ( _putenv(stl_putenv_var.c_str())==0 );
return success;
}// mySetEnv
...then (and only then!), all my low-level code that relies on envvars being set worked properly. You may face a similar issue here.
--- End quote ---
oBFusCATed:
This line is a bit strange:
--- Code: --- char buffer[stl_putenv_var.length()+1];
--- End code ---
because this is not a valid c++, but probably uses some language extension of gcc.
About the issue: have you looked at the code of wxsetenv? What does it do?
Have this problem been reported to wx devs?
They think it is fixed: http://trac.wxwidgets.org/ticket/1413
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version