Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on July 09, 2007, 08:23:38 pm

Title: The 09 July 2007 build (4241) is out.
Post by: killerbot on July 09, 2007, 08:23:38 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 (http://forums.codeblocks.org/index.php/topic,3232.0.html).

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

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

The 09 July 2007 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_win32.7z
  - Linux :
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_Ubuntu6.10+7.04_wx2.8.4.deb
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_Debian4.0_wx2.8.4.deb
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_suse100-102.wx28.i586.rpm (not yet)
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_fc4+5.i586.rpm (not yet)


Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 09 July 2007 build (4241) is out.
Post by: Grom on July 09, 2007, 08:52:06 pm
I have taken a look on to the roadmap in wiki. Do you update it sometimes or not?
Title: Re: The 09 July 2007 build (4241) is out.
Post by: stahta01 on July 09, 2007, 11:01:57 pm
Quote from: Grom on July 09, 2007, 08:52:06 pm
I have taken a look on to the roadmap in wiki. Do you update it sometimes or not?

Yes.

It was updated in last 90 days.

Tim S
Title: Re: The 09 July 2007 build (4241) is out.
Post by: Xaviou on July 09, 2007, 11:27:40 pm
Ubuntu 6.10 & 7.04 Amd64 .deb installer (build with wx263 and wx284) can be found here (http://www.esnips.com/web/CodeBlocks).
Title: Re: The 09 July 2007 build (4241) is out.
Post by: marfi on July 10, 2007, 08:27:27 am
Hi,
I'm affraid that precompiled headers support for GCC (MinGW) in C::B is broken. Only default option in Project settings ('Generate PCH alongside original header') works properly (but this option is not suitable for projects with multiple targets or for a case you want to subversion your code).

Option 'Generate PCH in a directory alongside original headers' creates directory named like the precompile header file with PCHs for every target, but only one of them is then used thus the compiler skips the PCHs for all others targets and writes warning message like this:
cc1plus.exe: warning: ./wx_pch.h.gch/Debug DLL_wx_pch_h_gch: created using different flags (for example this message apears also for Release target even a file named Release DLL_wx_pch_h_gch realy exists, etc...).

The last project option 'Generate PCH in the object output dir' doesn't work at all; the PCH created in OBJ dir is allways skiped and the original headers are used instead for all project targets.

(I use Win XP SP2 OS and the latest nightly build)
Title: Re: The 09 July 2007 build (4241) is out.
Post by: mandrav on July 10, 2007, 08:50:50 am
Quote
I'm affraid that precompiled headers support for GCC (MinGW) in C::B is broken.

No, it 's not broken.

Quote
Option 'Generate PCH in a directory alongside original headers' creates directory named like the precompile header file with PCHs for every target, but only one of them is then used thus the compiler skips the PCHs for all others targets and writes warning message like this:
cc1plus.exe: warning: ./wx_pch.h.gch/Debug DLL_wx_pch_h_gch: created using different flags (for example this message apears also for Release target even a file named Release DLL_wx_pch_h_gch realy exists, etc...).

That's normal. All PCHs (for every target) are generated in that dir. GCC picks up the correct one for each target but also displays a warning for the rest that it didn't use (which is normal). You can turn this warning off by removing the -Winvalid-pch option in your build options.

Quote
The last project option 'Generate PCH in the object output dir' doesn't work at all; the PCH created in OBJ dir is allways skiped and the original headers are used instead for all project targets.

You should know that the current dir has precedence over any search dirs added to the compiler (can be overridden with various tricks but none of them is boilerplate stuff we could do automatically). So, if you move your PCH header source file in a subdirectory instead of the root of your project tree, and reference it in your code like #include "some/pch.h", then the PCH from the object's output dir will be picked up correctly.
Title: Re: The 09 July 2007 build (4241) is out.
Post by: stahta01 on July 10, 2007, 09:00:05 am
The unofficial 4.x GCC builds has issues using some type PCH. I have no idea of the cause but one or two of the choices does not work quite right. This was true as of one or two months ago, I have not checked the new builds lately.

Tim S
Title: Re: The 09 July 2007 build (4241) is out.
Post by: marfi on July 10, 2007, 10:04:03 am
To Mandrav:

First of all I'd like to thank you for your prompt answer. I tried your advices but I'm not sure it helped me. Compilation with both non-default PCH options takes much more time that the prefered (default) one (same(?) time like without PCH). Moreover, the compiler command line generated for 'Generate PCH in the object output dir' is quite strange (see highlighted text below):

mingw32-g++.exe -Wall -pipe -mthreads -Winvalid-pch -D__GNUWIN32__ -D__WXMSW__ -DwxUSE_UNICODE -DWX_PRECOMP -O2  -include pch\wx_pch_dll.h -DWXUSINGDLL  -I..\obj\Win-gcc\wxsfdemo\ReleaseDLL\pch -I- -I..\obj\Win-gcc\wxsfdemo\ReleaseDLL\pch -I. -ID:\Lib\wxMSW-2.8\include -ID:\Lib\wxMSW-2.8\contrib\include -I..\include -ID:\Lib\wxMSW-2.8\lib\gcc_dll\mswu -IC:\mingw\include  -c D:\MyWork\Source\VC++\wxSF\example\MainFrame.cpp -o ..\obj\Win-gcc\wxsfdemo\ReleaseDLL\MainFrame.o
Title: Re: The 09 July 2007 build (4241) is out.
Post by: indigo0086 on July 10, 2007, 03:34:08 pm
There's a big problem when opening *.c files from the explorer (windows) when codeblocks isn't open.  If I try to codeblocks starts up and stays at the welcome screen, but explorer hangs and I can't bother the folder where I opened the file from.  I exit codeblocks and get the send/dns error message.
Title: Re: The 09 July 2007 build (4241) is out.
Post by: Albenejean on July 10, 2007, 04:05:37 pm
Quote
There's a big problem when opening *.c files from the explorer (windows) when codeblocks isn't open.  If I try to codeblocks starts up and stays at the welcome screen, but explorer hangs and I can't bother the folder where I opened the file from.  I exit codeblocks and get the send/dns error message.
Me too.
It's the last focused window that has this problem. For example, double clik on an .cbp file, the window containing this file hangs. When I open the same file with right click->"open with..."->"Choose a program", it is the "open with..." window that hangs.

I have to wait a 30-45 secs, then it's OK.

[EDIT]:
When I open a project from the windows explorer, and then immediatly closed CB, I receive sometimes an error from Windows that "Windows could not find the file xxx/MyProject.cbp, blablabla...". No error from CB, and it happens not always.

[EDIT2]: This is not a new bug. I have seen this in previously nightlies too.