Code::Blocks
September 17, 2014, 11:34:54 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: When registered with our forums, feel free to send a "here I am" post in http://forums.codeblocks.org/index.php/topic,14168.0.html to differ human beings from SPAM bots.
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1] 2 3  All   Go Down
  Send this topic  |  Print  
Author Topic: The 02 November 2012 build (8500) is out.  (Read 119432 times)
killerbot
Administrator
Lives here!
*****
Offline Offline

Posts: 4816


« on: November 02, 2012, 01:34:21 pm »

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc471-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc471-TDM.7z

The 02 November 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20121102_rev8500_win32.7z
  - Linux :
   none

Resolved Fixed:

  • fixed inability to work with files on UNC path's in project
  • fixed partial file corruption in project tree (not project file) when "saving as" the project under another drive
  • fixed bugs related to "save as" a project under a sub-folder on a different drive without layout
  • fixed a crash when compiling a single file as described here: http://forums.codeblocks.org/index.php/topic,17033.msg116227.html#msg116227 (on behalf of Jens)

Regressions/Confirmed/Annoying/Common bugs:


    Logged
    march1993
    Newcomer
    *
    Offline Offline

    Posts: 3


    « Reply #1 on: November 02, 2012, 03:22:59 pm »

    It seems that code completion doesn’t work properly with SDCC 3.2.0.
    Logged
    MortenMacFly
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 8639



    « Reply #2 on: November 02, 2012, 04:31:33 pm »

    It seems that code completion doesn’t work properly with SDCC 3.2.0.
    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.
    Logged

    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
    jens
    Administrator
    Lives here!
    *****
    Online Online

    Posts: 6594



    WWW
    « Reply #3 on: November 02, 2012, 09:15:29 pm »

    As usual:
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
    Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc16, fc17 and fc18) can be found in my rpm-repo .
    Packages for CentOS/RedHat 5 and 6 will follow. can be found there too.
    « Last Edit: November 03, 2012, 10:18:36 am by jens » Logged

    Regards

    Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
    march1993
    Newcomer
    *
    Offline Offline

    Posts: 3


    « Reply #4 on: November 03, 2012, 02:53:31 am »

    It seems that code completion doesn’t work properly with SDCC 3.2.0.
    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.

    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.
    Logged
    march1993
    Newcomer
    *
    Offline Offline

    Posts: 3


    « Reply #5 on: November 03, 2012, 02:54:25 am »

    It seems that code completion doesn’t work properly with SDCC 3.2.0.
    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.

    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.

    It seems that code::blocks works properly with an older version of SDCC.
    Logged
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4066


    Interests on OpenCV and Robotics


    WWW
    « Reply #6 on: November 03, 2012, 02:35:34 pm »

    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)


    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:\>


    So, I suspect the PATH variable was sometimes changed by compiler plugin? I will check an old nightly build version.
    Logged

    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4066


    Interests on OpenCV and Robotics


    WWW
    « Reply #7 on: November 03, 2012, 02:56:31 pm »

    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?
    Logged

    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4066


    Interests on OpenCV and Robotics


    WWW
    « Reply #8 on: November 04, 2012, 06:25:37 am »

    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.
    Logged

    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.
    oBFusCATed
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 7599


    « Reply #9 on: November 04, 2012, 10:37:20 am »

    This line is a bit strange:
    Code:
        char buffer[stl_putenv_var.length()+1];
    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
    « Last Edit: November 04, 2012, 10:39:06 am by oBFusCATed » Logged

    <debugger plugin maintainer>
    (most of the time I ignore long posts)
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4066


    Interests on OpenCV and Robotics


    WWW
    « Reply #10 on: November 04, 2012, 11:55:16 am »

    This line is a bit strange:
    Code:
        char buffer[stl_putenv_var.length()+1];
    because this is not a valid c++, but probably uses some language extension of gcc.
    Maybe, morten can say something about this.

    Quote
    About the issue: have you looked at the code of wxsetenv? What does it do?
    see below:
    Code:
    bool wxSetEnv(const wxString& WXUNUSED_IN_WINCE(var),
                  const wxChar *WXUNUSED_IN_WINCE(value))
    {
        // some compilers have putenv() or _putenv() or _wputenv() but it's better
        // to always use Win32 function directly instead of dealing with them
    #ifdef __WXWINCE__
        // no environment variables under CE
        return false;
    #else
        if ( !::SetEnvironmentVariable(var, value) )
        {
            wxLogLastError(_T("SetEnvironmentVariable"));

            return false;
        }

        return true;
    #endif
    }

    I can not see any reason why SetEnvironmentVariable failed.
    Quote
    Have this problem been reported to wx devs?
    I will report it if I have time.

    Quote
    It said:
    Quote
    Changed 4 years ago by neis
    Fixed by revision 42471, which should have ensured that it's correct in 2.8.0 and later.
    But it appears that the bug is still here in wx2.8.12.


    Edit:
    See here: http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__env.html

    Quote
    bool wxSetEnv    (    const wxString &     var,
          const wxString &     value
       )       

    Sets the value of the environment variable var (adding it if necessary) to value.

    Notice that under Windows platforms the program may have two different environment blocks: the first one is that of a Windows process and is always present, but the CRT may maintain its own independent copy of the environment. wxSetEnv() will always update the first copy, which means that wxGetEnv(), which uses it directly, will always return the expected value after this call. But wxSetEnv() only updates the second copy for some compilers/CRT implementations (currently only MSVC and MinGW which uses the same MSVC CRT) and so using wxGetenv() (notice the difference in case) may not return the updated value.

    Parameters
        var   The environment variable to be set, must not contain '=' character.
        value   New value of the variable.

    Returns
        true on success or false if changing the value failed.

    See Also
        wxUnsetEnv()

    Include file:

    #include <wx/utils.h>


    But I do not quite understand this description.
    « Last Edit: November 04, 2012, 11:57:20 am by ollydbg » Logged

    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.
    MortenMacFly
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 8639



    « Reply #11 on: November 04, 2012, 05:11:45 pm »

    This line is a bit strange:
    Code:
    char buffer[stl_putenv_var.length()+1];
    because this is not a valid c++, but probably uses some language extension of gcc.
    Maybe, morten can say something about this.
    Nope I can't other than it compiles and works just fine w/o specific extension (and why is it no C++, btw?!):
    http://www.cplusplus.com/reference/string/string/length/
    Its that same as char buffer[64]; or alike...
    Logged

    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
    oBFusCATed
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 7599


    « Reply #12 on: November 04, 2012, 05:14:53 pm »

    Its that same as char buffer[64]; or alike...
    No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?
    Logged

    <debugger plugin maintainer>
    (most of the time I ignore long posts)
    p2rkw
    Almost regular
    **
    Offline Offline

    Posts: 141


    « Reply #13 on: November 04, 2012, 05:24:02 pm »

    Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
    '64' is compile time constant, string::length is run time constant. 'const' qualifier only allow to call length() on const object.
    « Last Edit: November 04, 2012, 05:27:12 pm by p2rkw » Logged
    MortenMacFly
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 8639



    « Reply #14 on: November 04, 2012, 05:31:07 pm »

    No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?
    No, why should I?

    Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
    So - according this its OK. And yes, of course I know its a variable and not a constant. I thought oBFusCATed meant the length() method not being standard and I wanted to point put that it returns a const size_t.

    BTW: I think we are getting off-topic ...
    Logged

    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
    Pages: [1] 2 3  All   Go Up
      Send this topic  |  Print  
     
    Jump to:  

    Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!