Author Topic: The 06 January 2009 build (5382) is out.  (Read 112369 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
The 06 January 2009 build (5382) is out.
« on: January 06, 2009, 09:21:32 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_wx289.7z

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

The 06 January 2009 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20090106_rev5382_win32.7z
  - Linux :
   none

Resolved Fixed:

  • changed saving and restoring of colours for IncSearch nad HighlightOccurrences to make better use of sdk
  • fixed wrong indexing of arrays in watches window, if gdb shows multiple occurrences as one, with the addition "<repeated xx times>"
  • really fixed a parsing error with stream operator (<<) (see r5007)
  • Applied patch by danselmi to fix automatic indentation after opening brace when the next non-white character is a closing brace
  • remember logger pane size when toggling with F2 (modified patch of elie)
  • If "Auto show/hide message pane" has changed in environment settings dialog, it will be used immediately (without restart of C::B)
  • After compiling with message "Nothing to be done." message pane will be closed if "Auto show/hide message pane" is activated.
  • Make sure that no deleted layouts remain in conf-file, if their amount decreased
  • HexEdit:
    * Code refactoring to prepare better architecture for parametrized views
    * Added possibility to chage view modes: Bin/Hex, 1,2,4,8 Bytes, Big-Endian/Little-Endian (in editor only, not yet in value preview)
    * Some svn properties update
  • ThreadSearch plugin : implemented the possibility to run many searches without deleting previous results
  • changed directory-layout if codeblocks gets build with automake, to make it more compliant with the "Filesystem Hierarchy Standard"
  • changed debian package-layout, to have arch-independent and arch-dependent files in different packages
  • added wxsmith development headers and a wxsmith conf-file for pkgconfig
  • added update-script for ChangeLog on linux-systems (needs to be called manually at the moment)
  • added missing contrib-plugin names in debian control file
  • added some missing headers to wxSmith's pkg-config list
  • HexEdit: Added ability to change the way columns count is calculated
  • Fixed: Build error under certain configurations (More to follow)
  • HexEdit: Fixed calculation of address
  • fixed bug in compiler autodetection for MinGW / gcc
  • ThreadSearch: implemented the possibility to remove search results from list or tree control
  • make sure that masterpath and extrapath of a toolchain executable come before default systempath in executables environment, to avoid conflicts with different versions with the same name
  • Fixed: Build warning under GCC-4.3.x
  • some better warning options for GCC
  • fix for drag and drop-bug : default behaviour is now not to start DDE/IPC when running C::B from inside C::B, to avoid problems when debugging C::B itself
  • upgraded to new wxscintilla version
  • new feature : changebar
  • renamed menu-entry for empty undo- and changebar-buffer to "Clear changes history", function names are changed accordingly
  • Fixed: Menu option "Clear history" looses icon in File > Recent files & Recent projects
  • Fixed: Few menu items enable/disabling

Regressions/Confirmed/Annoying/Common bugs:

  • toolbar-images-not-changing-state (is a wx problem/Win XP problem)


Offline Xaviou

  • Regular
  • ***
  • Posts: 402
    • X@v's wxStuff
Re: The 06 January 2009 build (5382) is out.
« Reply #1 on: January 06, 2009, 11:39:13 pm »
Ubuntu 7.04 to 8.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx288) can be found here or here (direct link).
The french wxWidgets site : http://www.wxdev.fr
My wxWidgets's stuff : https://wxstuff.xaviou.fr/

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 06 January 2009 build (5382) is out.
« Reply #2 on: January 07, 2009, 12:14:06 am »
I just uploaded the nightlies for debian to my server.

madscientist

  • Guest
Re: The 06 January 2009 build (5382) is out.
« Reply #3 on: January 07, 2009, 01:10:02 am »
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 January 2009 build (5382) is out.
« Reply #4 on: January 07, 2009, 03:18:54 am »
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.
I can't reproduce this problem in my system.

To OP:
Thanks for sharing!
The Drag toolbar crash problem seems fixed. so, I upgrade the wxmsw28u_gcc_cb_wx288 to wxmsw28u_gcc_cb_wx289, it works fine. still exists, so I should use wx288 instead.

Thank you! I will continue testing.
« Last Edit: January 07, 2009, 03:22:21 am by ollydbg »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 January 2009 build (5382) is out.
« Reply #5 on: January 07, 2009, 04:05:49 pm »
I think there is a bug when debugging. (I'm using windows XP and Mingw from TDragon.

My program was linked to the debug library of opencv. which are located in:

F:\test1\lib\***
the source file is located in
F:\opencv\src\cxcore\***

It seems that I can't set break points  in the source file. GDB complaints that :
Code
> break "F:/opencv/src/cxcore/cxarray.cpp:104"
No source file named F:/opencv/src/cxcore/cxarray.cpp.
Breakpoint 3 ("F:/opencv/src/cxcore/cxarray.cpp:104) pending.
>>>>>>cb_gdb:

But my source file is exactly named "F:/opencv/src/cxcore/cxarray.cpp", my program will call some function in the cxarray.cpp.

Also,  another problem is I can't "step into" the source code. ( This functionality is available in the last svn release).

The problem seems happens in this SVN version. The last version works well as I can remember.

I search the forum and found some related discussion.
I download the zip from the thread:
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
And still it can't set break point in the DLL source file.

Some one can explain it?
Thanks.
« Last Edit: January 07, 2009, 04:22:41 pm by ollydbg »
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.

Offline rhf

  • Multiple posting newcomer
  • *
  • Posts: 123
Re: The 06 January 2009 build (5382) is out.
« Reply #6 on: January 07, 2009, 04:55:17 pm »
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 January 2009 build (5382) is out.
« Reply #7 on: January 07, 2009, 05:38:32 pm »
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
HI, Thanks for your hint. Actually, I already use the TDM's 4.3.2 TDM-2 2008-12-09 as you mentioned.
Maybe, it is related to the "setting break point in a header file" issue, maybe not, I'm not sure. :(

The problem seems comes from "How does the compiler and GDB handle with the path of source file".
I test the zip file from :
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390

There are two build targets. One is a exe file. The other is a DLL file.
The exe file will load the DLL file when it runs. Both of these targets were build with Debug enabled. So, I think that in the "TestDLL.dll", there are some part to reference it's source file path.

I put the project in "C:\DebugTest"

main.cpp was located in "C:\DebugTest\TestApp"
dllmain.cpp was located in "C:\DebugTest\TestDLL"

But I can't set break point in the "dllmain.cpp".

GDB reported:
Code
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.

It is very confused that sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB. (I'm not sure how does the linker handle the path related issue).

So, I'm totally lost in this problem :(, can someone give a clarification? Thanks.
« Last Edit: January 07, 2009, 05:41:41 pm by ollydbg »
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.

Offline rhf

  • Multiple posting newcomer
  • *
  • Posts: 123
Re: The 06 January 2009 build (5382) is out.
« Reply #8 on: January 07, 2009, 06:15:37 pm »
sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB.

Interesting. I have had the same problem debugging using relative paths.  I now generally use absolute paths in my Search directories, and debugging seems to work much better. This sure looks like a bug, but I haven't been able to create a simple test case to demonstrate it

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 06 January 2009 build (5382) is out.
« Reply #9 on: January 07, 2009, 06:24:57 pm »
GDB reported:
Code
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.

The gdb-message is normal for shared libraries that are not yet loaded.
The breakpoint is pending means that it's address can not (yet)  be resolved.
It will be reevaluated after the lib is loaded.

It has nothing to do with the step-into issue.

If the dll and the exe are compiled with C::B make sure you have not (accidently) unchecked "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings (rightmost tab) -> Advanced options... -> Others -> Use full path for source files (GDB workaround):".

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 January 2009 build (5382) is out.
« Reply #10 on: January 07, 2009, 06:36:58 pm »
Thanks jens.
I have this option enable by default.
see the attachment image.

I also enable the full compiler output, when compiling, the output are here:
Code
-------------- Build: TestDLL in cb_debug_test ---------------

[ 50.0%] mingw32-g++.exe -Wall -g     -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw  -c C:\DebugTest\TestDLL\dllmain.cpp -o .objs\TestDLL\dllmain.o
[100.0%] mingw32-g++.exe -shared  -Wl,--out-implib=bin\libTestDLL.a -Wl,--dll  .objs\TestDLL\dllmain.o   -o bin\TestDLL.dll 
Creating library file: bin\libTestDLL.a
Output size is 22.46 KB

-------------- Build: TestApp in cb_debug_test ---------------

[ 50.0%] mingw32-g++.exe -Wall -g     -I. -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw  -c C:\DebugTest\TestApp\main.cpp -o .objs\TestApp\main.o
C:\DebugTest\TestApp\main.cpp: In function 'void LoadDllPlugin()':
C:\DebugTest\TestApp\main.cpp:103: warning: unused variable 'status'
[100.0%] mingw32-g++.exe  -o bin\TestApp.exe .objs\TestApp\main.o     -mwindows
Output size is 32.17 KB
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 1 warnings


When debugging the exe file, I still can't set break point in anywhere in the "dllmain.cpp".
If you have enough time, you could help to test the zip file in that thread. Thanks.
http://forums.codeblocks.org/index.php?action=dlattach;topic=4896.0;attach=1707


correct!  setting break points in the code below works!

Code
// a sample exported function
void __declspec(dllexport) MyFunction(const LPCSTR sometext)
{
    /** SET BREAK POINT HERE VVVVVVVVVVV **/
    MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
    /** SET BREAK POINT HERE ^^^^^^^^^^^^ **/
}


The breakpoints can't be set in the function of DllMain.



[attachment deleted by admin]
« Last Edit: January 07, 2009, 06:44:51 pm by ollydbg »
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 06 January 2009 build (5382) is out.
« Reply #11 on: January 07, 2009, 07:36:46 pm »
The breakpoints can't be set in the function of DllMain.

I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.

g++ is 4.2.1-dw2:
Code
C:\Dokumente und Einstellungen\jens>g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --prog
ram-suffix=-dw2 --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-thread
s --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --disable-sjlj-exceptions --enable-li
bstdcxx-debug --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-version-specific-runtime-libs --disable-boot
strap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)

gdb is 6.7.50 on my XP partition:
Code
GNU gdb 6.7.50.20071127
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".

Iwill test it with gdb 6.8 on w2k too, this evening.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 06 January 2009 build (5382) is out.
« Reply #12 on: January 07, 2009, 08:44:56 pm »
I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.
For me it still does not work. But I am using the GCC 3.4.5 compiler suite ang GDB 6.6 (otherwise I cannot debug into wx code). It seems an issue with the compiler/debugger version obviously... Oh dear... Should I really finally upgrade my dev frameworks?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 January 2009 build (5382) is out.
« Reply #13 on: January 08, 2009, 03:39:42 am »
It is very interesting, when I renamed the project folder name from "C:\DebugTest" to "C:\DebugTest1".
Then I open the cbp file and debug without rebuild the project. Then the gdb complaint that: (I'm using the TDM-mingw version)

Code
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/TestApp.exe
Working dir : C:\DebugTest1\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined in loaded symbols.
>>>>>>cb_gdb:
> show directories
Source directories searched: $cdir;$cwd
>>>>>>cb_gdb:
> directory C:/DebugTest1/
>>>>>>cb_gdb:
> break "C:/DebugTest1/TestApp/main.cpp:26"
No source file named C:/DebugTest1/TestApp/main.cpp in loaded symbols.
Breakpoint 1 ("C:/DebugTest1/TestApp/main.cpp:26) pending.
>>>>>>cb_gdb:

You can see when gdb started, it use the command line:
Code
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/TestApp.exe

which has a parameter "-fullname", so I can't set break points in anywhere of the source file. Because the debug information in both exe and DLL file were reference to " C:\DebugTest\***".
As a workaround, I should rebuild the Target.




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.

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 06 January 2009 build (5382) is out.
« Reply #14 on: January 08, 2009, 02:33:35 pm »
Code
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp  (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp  (working copy)
@@ -36,7 +36,10 @@
     wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
     m_VerStr = compiler->GetVersionString();
     wxString pch_prepend;
-    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+//    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+    // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+    // compiler->GetVersionString() return is empty string
+    bool IsGcc4 = true;

     // for PCH to work, the very first include dir *must* be the object output dir
     // *only* if PCH is generated in the object output dir