News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

The 28 June 2006 build is out.

Started by killerbot, June 28, 2006, 09:42:21 PM

Previous topic - Next topic

killerbot

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

A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z

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

For support of ansi builds, a link to the ansi windows wxWidget dll (2.6.2) for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 28 June 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060628_rev2628_win32.7z
  - Linux :
         http://download.berlios.de/codeblocks/CB_20060628_rev2628_Ubuntu6.06.deb (not this time)
         http://download.berlios.de/codeblocks/CB_20060628_rev2628_fc4+5.rpm


Resolved Fixed:


  • Applied Morten's patch to ToolsManager so it can also launch tools detached from it
  • Old wxSmith: Fixed bug #7967 - XRC and WXS files often not in sync
  • fix uncomment unicode bug (don't use wxScintilla::Replace() on unicode, non western characters)

Regressions/Confirmed/Annoying/Common bugs:


  • toolbar-images-not-changing-state (is a wx problem/Win XP problem)
  • there are several issues with Code Completion (is being redesigned : work in progress)
  • menu items with icon not correctly aligned (since wx263)


Tjaalie

I found an bug in the snake game.
If you press 'P' after you ran out of lives
you can play futher with -1 lives and when you die
you just go to -2, -3....

Tjaalie,

ironhead

I'm not sure if this is a bug with the Nightlies or C::B itself.  I just got the following when compiling:

In file included from main.cpp:33:
D:/Dev/MinGW/include/stdio.h:330: error: ISO C++ does not support `long long'
In file included from D:/Dev/MinGW/include/stdio.h:399,
                 from main.cpp:33:
D:/Dev/MinGW/include/sys/types.h:32: error: ISO C++ does not support `long long'
D:/Dev/MinGW/include/sys/types.h:110: error: ISO C++ does not support `long long'
D:/Dev/MinGW/include/sys/types.h:115: error: ISO C++ does not support `long long'
In file included from main.cpp:33:
D:/Dev/MinGW/include/stdio.h:416:14: warning: use of C99 long long integer constant

I'm using the MinGW gcc, and types.h defines:

#ifdef __MSVCRT__
typedef long long fpos_t;
#else
typedef long   fpos_t;
#endif

So I must assume the __MSVCRT__ is being defined by C::B during the compile.  I can compile this using my own Makefile and mingw32-make using the same compiler flags that I have defined in my C::B project file.

If this is actually a C::B bug let me know and I will file a bug report on the C::B Berlios project page.

Cheers!

ironhead

Quote from: ironhead on June 29, 2006, 12:37:29 PM
So I must assume the __MSVCRT__ is being defined by C::B during the compile.  I can compile this using my own Makefile and mingw32-make using the same compiler flags that I have defined in my C::B project file.

Never mind.  It seems to be related to the -ID:\Dev\MinGW\include.  I didn't have that in my own Makefile, when I added it I got the same error.  The interesting this is that if I don't include it (and remove the path from the include directories), everything compiles without any warnings.

I'll follow up with the MinGW folks...

thomas

__MSVCRT__ is certainly defined by MinGW, because MinGW builds on the MSVCRT.

Before you bother the MinGW guys you might want to make sure you have turned off --pedantic and --pedantic-errors. These are the common cause of warnings like the one about long long.
Also, you might want to make sure that you did not make a setup error (mixing headers from 5 different versions, for example).

The reason why I am saying this is that it works 100% nicely for me (I can include stdio.h without getting any warnings, and I can certainly use fpos_t just normal). Very likely, you'll get a similar answer from the MinGW team.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

ironhead

It turns out the issue is that g++ assumes that any header found via a '-I' path is not a system header.  As such, since in my case I had <stdio.h> and it was found in -ID:\Dev\MinGW\include (since the path was defined in the 'include' directories) the g++ compiler did not consider a system header.  Since I wanted to keep the '-pedantic', I removed the path from the include directories (in the compiler setup dialog), since g++ knows where to find it's own headers, everything works fine.

By default C::B auto-populates (at least for me it did) the include, lib and resource directories to 'C:\MinGW\include' or 'C:\MinGW\lib', perhaps it should not for the gcc compiler configuration, so that this issue is not experienced by other users (thereby hopefully cutting down on some false positive bug reports).

To thomas's point this is only if you specify '-pedantic', and as thomas pointed the '__MSVCRT__' was a red herring, I realized that too after thinking about it (unfortunately after I posted).

byo

Quote from: Tjaalie on June 29, 2006, 11:07:19 AM
I found an bug in the snake game.
If you press 'P' after you ran out of lives
you can play futher with -1 lives and when you die
you just go to -2, -3....

Tjaalie,

Could be threated as cheat code  :lol:

sethjackson

Quote from: byo on June 29, 2006, 07:05:28 PM
Quote from: Tjaalie on June 29, 2006, 11:07:19 AM
I found an bug in the snake game.
If you press 'P' after you ran out of lives
you can play futher with -1 lives and when you die
you just go to -2, -3....

Tjaalie,

Could be threated as cheat code  :lol:

:lol: :lol: :lol: