In Debian Lenny testting, i build CB, but the version info can not show.
In 'Start here' page, it's show: svn build rev 0 (unknown date) gcc 4.3.1 Linux/unicode
I get the source from SVN by 'svn checkout svn://svn.berlios.de/codeblocks/trunk ~/Sources/CodeBlocks'In Debian Lenny testting, i build CB, but the version info can not show.
In 'Start here' page, it's show: svn build rev 0 (unknown date) gcc 4.3.1 Linux/unicode
you need svn to fetch that info
There appears to be a rather odd bug Ctrl-Delete doesn't delete the current word, it calls the Find Declaration function and, in my case, brings up the Multiple Matches dialog.
Code::Blocks SVN REV5106
Windows XP SP 2
A source tar-ball (usable on linux and windows) and binaries for debian (32 and 64 bit) are available on my server (http://apt.jenslody.de/).How to install old version? e.g. 5093 ?
It shows as svn5105, but it's the same version (there are only some small patches (https://apt.jenslody.de/patchlist.htm)), svn5106 is a change outside trunk.
The easiest way is to use synaptic and force a version (chose the package to install and press Ctrl+E).A source tar-ball (usable on linux and windows) and binaries for debian (32 and 64 bit) are available on my server (http://apt.jenslody.de/).How to install old version? e.g. 5093 ?
It shows as svn5105, but it's the same version (there are only some small patches (https://apt.jenslody.de/patchlist.htm)), svn5106 is a change outside trunk.
I want: sudo apt-get install codeblocks={5093}, but it's failure.
thanks!
Now SVN5105 can't work in my Debian OS.
sudo apt-get install codeblocks=1.0svn5093-1'Search directories' not work on Debian!
When compile, error info:
/media/disk/project/pmoney/src/app.cpp|5|error: calling fdopen: Bad file descriptor|
and is line is ' #include "pch.h" ', and pch.h dir is /include/pch.h
'Search directories' not work on Debian!
When compile, error info:
/media/disk/project/pmoney/src/app.cpp|5|error: calling fdopen: Bad file descriptor|
and is line is ' #include "pch.h" ', and pch.h dir is /include/pch.h
When i close CB, but the PC so slow, so i click 'close button' again, and CB crash!
if click CB's close btn two times, CB will crash.
You report a number of crashes which no other users / devs can confirm which is really weird.
Because you computer is fast, but my computer is slow.
When i close CB's 'close btn', CB can not shut. so i close CB's 'Close Button' again, then, CB crash!
I can reproduce it and I'm working on a fix. Seems as if ProjectManager is accessed after it was already freed.When i close CB, but the PC so slow, so i click 'close button' again, and CB crash!
if click CB's close btn two times, CB will crash.
You report a number of crashes which no other users / devs can confirm which is really weird.
Index: src/src/main.cpp
===================================================================
--- src/src/main.cpp (revision 5106)
+++ src/src/main.cpp (working copy)
@@ -2577,6 +2577,9 @@
void MainFrame::OnApplicationClose(wxCloseEvent& event)
{
+ if (m_InitiatedShutdown)
+ return;
+
CodeBlocksEvent evt(cbEVT_APP_START_SHUTDOWN);
Manager::Get()->ProcessEvent(evt);
Manager::Yield();
Charset question.Maybe with "autochanged" you mean that when you open your file its encoding is wrongly detected.
'Settings-->Editor-->General Settings-->Default encoding when opening files'Charset question.Maybe with "autochanged" you mean that when you open your file its encoding is wrongly detected.
In that case you can force an encoding, when opening the files, in the Settings-->Editor-->General Settings-->Default encoding when opening files.
Regards, XayC
As there was no reaction about the patch I posted here as fix for the reported crash I have put it into the tracker on berlios:There was a reaction, but not visible... I have applied it since "day one" and had in mind to test it. But it won't get lost as it is in my local copy... don't you worry... ;-)
I don't know if this post belongs to this topic or it should go to plugins section, so excuse me if I'm wrong...
I've found the cause of bug 13447 about wxSmith on 64-bit Linux (http://developer.berlios.de/bugs/?func=detailbug&bug_id=13447&group_id=5358 ) and described how to fix it (redeclare numeric properties of supported components as 'long's). Would some of C::B developers include the full fix in future nightbuild please?..
I will upload patched svn-binaries for debian to my repo this evening.
when i try to compile svn 5116 my HDD freaks out at Headerfixup when it trys to make the .o fileI 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.
weird isn't it
only hdd work the cpu is in idle mod
this is causing on linux
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.
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.
Hehe... see! Thanks! :-)I believe there should be a mystic disable-plugin=headerfixup switch or something..."--with-contrib-plugins=all,-headerfixup" is the way to go.
--- /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
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 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).
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.
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.
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.
I think a colleague of mine is having the same build issue but on 32 bit (ubuntu). I can only check this in 3 weeks time. But maybe it is best not to 'if' in the configure.in and Makefile.am, that way we can keep the hack very small, and located to 1 file with a minimum of logic ? After all it is just for a plug-in.I have also applied the correction for ubuntu 32 bits for the two last nightly.