The 03 november 2006 build is out.

[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://prdownload.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://prdownload.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb_wx2.6.3p2.7z

The 03 November 2006 build is out.
  - Windows : http://prdownload.berlios.de/codeblocks/CB_20061103_rev3175_win32.7z
  - Linux :
         http://prdownload.berlios.de/codeblocks/CB_20061103_rev3175_Ubuntu6.06.deb
         http://prdownload.berlios.de/codeblocks/CB_20061103_rev3175_suse100+101.rpm (not yet)
         http://prdownload.berlios.de/codeblocks/CB_20061103_rev3175_fc4+5.rpm (not yet)


Resolved Fixed:

• Fixed setting breakpoints in files not belonging to project
• fixed crash when trying to debug in a thread and the debugger wasn't active anymore
• updated wxFlatNotebook to eranifs first revision in svn :-)
• add "AddUser" button in todo plugin -> new users can be added again (this was lost in the combobox ->choice control replacement)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• menu items with icon not correctly aligned (since wx263)

[sethjackson]

Windows ANSI build here.

[cstudent]

Ubuntu 6.10 (Edgy) build here.

[oz]

Ubuntu 6.10 (Edgy) build here.

thanks for your work. could you also provide the link that where to download the prerequisite packages? such as the libwxbase-2.6-0. I did not find it at packages.ubuntu.com. thanks

FOUND it at packages.ubuntu.com/edgy/libs

[bdolter]

I've got a problem that didn't exist before Nov 3 build,

I'm currently working on a C windows program that loads a DLL plugin into memory and then executes it.  Using the November 2 build, I can set breakpoints throughout the DLL and codeblocks will stop during debugging.   But some of the debugging changes made during the November 3 build has broke that.  I can set the break point and step into the DLL, but the debugger will not stop at any of my DLL break point if I click on the continue button.  I just downloaded the Dec 11 build as well and the problem seems to be there as well.

Has anyone else seen this???

Brad Dolter

[MortenMacFly]

Has anyone else seen this???

Do you have setup a project or is this a single file (without project) you are trying to compile?
Could you provide us with a project (zipped) attached to a post and a step-by-step instruction how to reproduce? Because I can't.
With regards, Morten.
Ps.: Please don't hijack old forum threads.
Pps.: Note for the record: Within r3171+ were debugger changes that could be related.

[bdolter]

Ok,

I've written some quick source to demostrate the problem.  Both app and dll are in the same workspace but differenct projects.  The idea is that a application would load a dll and retrieve a set of symbols at runtime.  For debugging the dll, I simply added the imports library to the link list and put ifdefs around the "GetProcAddress", this way I was able to debug the DLL up untill the Nov 3 build.

To Test, Load the Nov 2 Build.
load my workspace provided.
compile TestDLL, then TestAPP
set a break point in TestDLL, dllmain.c line 10 (I commented it). 
Now run TestApp in debug and you should get a break at line 10 of the DLL.

Now Load the Nov 3 (or later) build,
repeat, and you should get no breaks in the DLL.  You can set into the DLL, but no
break points will work.

For the record, where should I have posted this bug.  I didn't mean to "hijack" a thread.
Since this was bug that crept in between Nov 2 and Nov 3, I assumed the Nov 3 Nightly
build thread was the place to document it.

Brad


[attachment deleted by admin]

[tiwag]

i can confirm this breakpoints issue,
even if the project is set up as targets (instead of using two projects) for app and dll it doesn't work for me.

[attachment deleted by admin]

[MortenMacFly]

i can confirm this breakpoints issue,

Confirmed here, too. Already testing whether it's related to r3171 (which I don't think so though)...
With regards, Morten.

P.s.: Coming back to where to post: The problem I see that I personally focus on new messages because there are in general so many messages each day. So hijacking an *old* thread might result in being "ignored" although by mistake. I would have expected this as a new topic in the development forum. Surely with the advice that this happened during 2nd/3rd November. But it's alright just as it is... I didn't mean to be a nitpicker...

[MortenMacFly]

OK - confirmed that it's related to the changes in r3171. If you uncomment them it'll work again properly. Unfortunately these changes (done by Yiannis) actually should avoid exactly that misbehavior. I need to talk to Yiannis about that...
With regards, Morten.

Ps:: As a QuickFix (for bdolter):
- goto the file debuggerstate.cpp
- search for the comment:

Code

// for foreign files, we still should use a relative path

- remove (comment) the complete else section.

[tiwag]

please look also at the sample i've posted above, where reverting rev 3171 doesn't help !

i don't know if this is a gdb issue ? but it's interesting
only one breakboint was set, but gdb reports
breakpoint #2 resolved AFTER closing the application,
and then CB is out of order - the app is no more running,
but CB obviously doesn't recognice it and you have to close
the debugger-session manually.

[MortenMacFly]

please look also at the sample i've posted above, where reverting rev 3171 doesn't help !

Right... confirmed. :-( So does using a relative path for the file to "breakpoint into" does work at all???
With regards, Morten.

[bdolter]

Thanks for the quick fix  , I will try it tomorrow.

reguards,
Brad Dolter