The 25 June 2008 build (5106) is out.

[Der Meister]

I can confirm this. The problem is the file defaults.cpp. Compiling it takes needs more that 1GB of RAM but on machines with less physical RAM (like mine, I have only 512MB here) a huge amount of swap space will be used which slows the computer down or makes it even unusable. After about five minutes I aborted the compiler and decided not to compile this plugin.

[PsYhLo]

i have 2GB ram and 1GB swap  :shock:
 :lol:

edit
sorry that was offtopic

what is causing this

[Jenna]

when i try to compile svn 5116 my HDD freaks out at Headerfixup when it trys to make the .o file
weird isn't it
only hdd work the cpu is in idle mod
this is causing on linux

I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.

This only happens with "./configure make ..." not when compiling with C::B.

And it does not start with r5116.

[MortenMacFly]

This only happens with "./configure make ..." not when compiling with C::B.

Well, *that* is interesting... But I have no clue why this happens. If you look into the code it's pretty much simple. Why GCC freaks out?! I don't know. Any what's most strange is why this does not happen when compiling with C::B itself because the GCC call should in fact be exactly the same when compiling this file. Well - where to go from here? I won't undo the changes in SVN. Whoever has issues compiling just use C::B for compiling or leave out this plugin. I believe there should be a mystic disable-plugin=headerfixup switch or something... I don't know I am not a make guy (anymore... this cost me too much hairs in the past ;-)). Probably we will remove this plugin from the make system.

It also seems to work with different compiler(s). Probably splitting up the file even more could be another option (but would be stupid to "fix" a compiler bug...?!). Finally the plans for this plugin are that actually these values are read from a file at run-time. But this is a long-term change and may make not even sense...

[Der Meister]

I believe there should be a mystic disable-plugin=headerfixup switch or something... I don't know I am not a make guy (anymore... this cost me too much hairs in the past ;-)).

"--with-contrib-plugins=all,-headerfixup" is the way to go.

[MortenMacFly]

I believe there should be a mystic disable-plugin=headerfixup switch or something...

"--with-contrib-plugins=all,-headerfixup" is the way to go.

Hehe... see! Thanks! :-)

[killerbot]

this is what I showed at : http://forums.codeblocks.org/index.php/topic,8756.0.html

Things is if i do a make clean first, it compiles.

[Jenna]

I found the cause for the memory-eating:
it's the optimization-flag.

I'm not an automake-guru, so it takes me a while to fin out how to switch it off only for headerfixup-plugin.
But at least it's quite easy.

Here is a patch for "Makefile.am" of headerfixup-plugin.
After applying it you have to run "./bootstrap" to regenerate "Makefile.in" what is used by "./configure".

Code

--- /usr/src/c/codeblocks/codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-09 07:20:42.000000000 +0200
+++ codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am       2008-07-10 23:05:33.000000000 +0200
@@ -2,6 +2,8 @@
            -I$(top_srcdir)/src/include \
            -I$(top_srcdir)/src/include/wxscintilla/include

+CXXFLAGS = @CXXFLAGS@ -O0
+
 libdir = $(pkgdatadir)/plugins

 lib_LTLIBRARIES = libheaderfixup.la

This will add a "-O0" (the second one is a zero) to "CXXFLAGS" and overrides the "-O2" set before. The other flags will not be touched.

[olelukoie]

I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.

I do not have such enormous memory consuming by compiling this file - on my 64-bit system (mandriva linux 2009.0 alpha with GCC 4.3.1 prerelease) it takes about 850 Mb of RAM and ~57 seconds (CPU Intel E6750). And after i've split the function SetDefaultsWxWidgets into two (SetDefaultsWxWidgets26 and SetDefaultsWxWidgets28 plus "wrapper" SetDefaultsWxWidgets that calls them) compiling this file took about the same time but almost twice less memory (~450 Mb).

[Jenna]

I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.

I do not have such enormous memory consuming by compiling this file - on my 64-bit system (mandriva linux 2009.0 alpha with GCC 4.3.1 prerelease) it takes about 850 Mb of RAM and ~57 seconds (CPU Intel E6750). And after i've split the function SetDefaultsWxWidgets into two (SetDefaultsWxWidgets26 and SetDefaultsWxWidgets28 plus "wrapper" SetDefaultsWxWidgets that calls them) compiling this file took about the same time but almost twice less memory (~450 Mb).

 I didn't measure the time, but with no optimization the compilation of "defaults.cpp" needs less then 10 seconds.
With optimization it needs some minutes.

I can't test what happens if I split the SetDefaultWxWidgets-function, my laptop is at home and I am at work :cry: .
My only linux-system here is on my USB-stick and it's 32-bit only.

[mslomp]

rather than apply a patch to override the optimization flag, you can just do:
# make CXXFLAGS=-O0

i'm working with a debug build of gcc (4.4) in order to check this issue,
and i hope soon to find the black hole and possibly submit a patch to the gcc trunk.

[Jenna]

rather than apply a patch to override the optimization flag, you can just do:
# make CXXFLAGS=-O0

i'm working with a debug build of gcc (4.4) in order to check this issue,
and i hope soon to find the black hole and possibly submit a patch to the gcc trunk.

Thanks for your reply.

I know I can ovverride CXXFLAGS when I do the make, but that overrides it afaik for the whole build-process and therefore for the complete C::B suite.
The patch to Makefile.am of headefixup-plugin only stops optimization for this one plugin.

[blamek]

i don't know whether is it a bug or feature (and if it was already reported): cb doesn't remember which files were opened in previous session and after restart all files from current projects will be opened.

regards

Andrzej B.

[Jenna]

i don't know whether is it a bug or feature (and if it was already reported): cb doesn't remember which files were opened in previous session and after restart all files from current projects will be opened.

regards

Andrzej B.

Can you check your settings in "Settings -> Environment... -> General settings" ?
Which radiobutton is checked under "On applicaton startup" and "On project load" ?

[blamek]

That was exactly what i was looking for. I must have missed that option. Thanks