Author Topic: parsertest project, Window refresh issue, rev 7788  (Read 25711 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
parsertest project, Window refresh issue, rev 7788
« on: February 11, 2012, 03:35:27 am »
See the screen shot, it looks like we need to force the main window to refresh when the progress dialog dismissed.


PS: The build-log panel should be refreshed too in some cases (I sometimes see this panel does not refreshed when C::B activated) :)
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9604
Re: parsertest project, Window refresh issue, rev 7788
« Reply #1 on: February 11, 2012, 06:21:53 am »
See the screen shot, it looks like we need to force the main window to refresh when the progress dialog dismissed.

Hmmm... you shouldn't actually see the main window when thee progress dialog is shown as it is hidden (in frame.cpp by calling Hide()). How did you manage to do that? (Doesn't happen here). :o
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #2 on: February 11, 2012, 06:33:57 am »
Hmmm... you shouldn't actually see the main window when thee progress dialog is shown as it is hidden (in frame.cpp by calling Hide()). How did you manage to do that? (Doesn't happen here). :o
The screen shot shows that the progress dialog is already closed. but I need to scroll on the textctrl to let the mainframe show its content correctly. This is the same issue when sometimes I see in build-log panel under c::b.

I'm using XP, wx2.8.12.
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: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #3 on: February 15, 2012, 06:36:37 am »
It looks like there is a fatal bug in wxWidgets 2.8.12 (windows).

I even add code like below:
Code: [Select]
   Show();

    m_LogCtrl->Refresh();
    m_LogCtrl->Update();

But the logCtrl still not refreshed. This is the same behavior as the build-log.

Any one have meet this kind of problem?
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: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #4 on: February 15, 2012, 08:56:24 am »
Ok, I find the reason:

In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.

I have tried another option which I enable wxTE_RICH, the bug happens again.

I'm not sure what's the exact meaning of those options. See the documents:

Quote
wxTE_RICH  Use rich text control under Win32, this allows to have more than 64KB of text in the control even under Win9x. This style is ignored under other platforms. 
wxTE_RICH2  Use rich text control version 2.0 or 3.0 under Win32, this style is ignored under other platforms 
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9604
Re: parsertest project, Window refresh issue, rev 7788
« Reply #5 on: February 15, 2012, 09:13:36 am »
In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.
There have been bug reports on this style and many improvements recently in the wx trunk version (a.k.a. 2.9.x) for rich text controls. If its a wx issue I'd say try with wx 2.9.x - if the error is gone, ignore it. In the end it's just a test project.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #6 on: February 15, 2012, 09:30:12 am »
In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.
There have been bug reports on this style and many improvements recently in the wx trunk version (a.k.a. 2.9.x) for rich text controls. If its a wx issue I'd say try with wx 2.9.x - if the error is gone, ignore it. In the end it's just a test project.
Thanks, but the issue also affect the current c::b's source code, see here
Code: [Select]
wxWindow* TextCtrlLogger::CreateControl(wxWindow* parent)
{
    if (!control)
        control = new wxTextCtrl(parent, -1, wxEmptyString, wxDefaultPosition, wxDefaultSize, wxTE_MULTILINE | wxTE_READONLY | wxTE_RICH | wxTE_NOHIDESEL | wxTE_AUTO_URL);
    return control;
}

Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.
« Last Edit: February 15, 2012, 10:04:06 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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12892
    • Travis build status
Re: parsertest project, Window refresh issue, rev 7788
« Reply #7 on: February 15, 2012, 10:35:03 am »
Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.
I doubt, because we will use the formatting, also it works as expected on linux :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #8 on: February 15, 2012, 11:28:39 am »
Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.
I doubt, because we will use the formatting, also it works as expected on linux :)

The refresh issue is very annoying under windows.  :(

It looks like wxTE_RICH and wxTE_RICH2 only affect the win32 platform.
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12892
    • Travis build status
Re: parsertest project, Window refresh issue, rev 7788
« Reply #9 on: February 15, 2012, 11:39:48 am »
The only thing you could do is to test it with wx2.9 from wx's trunk and then report to wx's guys if the problem is still there.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #10 on: February 16, 2012, 01:43:15 am »
The only thing you could do is to test it with wx2.9 from wx's trunk and then report to wx's guys if the problem is still there.
OK, I have just create a very simple test project against wx2.8 and wx trunk(2.9.x).

The result is: This issue does NOT happen in the wx trunk.  ;)
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12892
    • Travis build status
Re: parsertest project, Window refresh issue, rev 7788
« Reply #11 on: February 16, 2012, 01:56:18 am »
Now you can try to find the correct commit and then produce a backport patch (if possible). :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9604
Re: parsertest project, Window refresh issue, rev 7788
« Reply #12 on: February 16, 2012, 08:58:04 am »
Now you can try to find the correct commit and then produce a backport patch (if possible). :)
I wouldn't do it. We will move to wx 2.9 anyways sooner or later and I'd rather not make C::B depend on a self-patched version of wxWidgets.

Instead, you may ask the wxWidgets guys if it is possible to backport this specific stuff to the 2.8 branch (maybe it is already... who knows...).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12892
    • Travis build status
Re: parsertest project, Window refresh issue, rev 7788
« Reply #13 on: February 16, 2012, 09:34:44 am »
Instead, you may ask the wxWidgets guys if it is possible to backport this specific stuff to the 2.8 branch (maybe it is already... who knows...).
I doubt, they'll bother with another version of 2.8.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9604
Re: parsertest project, Window refresh issue, rev 7788
« Reply #14 on: February 16, 2012, 10:23:35 am »
I doubt, they'll bother with another version of 2.8.
Are you really sure? Because there are plenty of commits on the wx28 branch since v2.8.12, including back-ports from v2.9.x ...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12892
    • Travis build status
Re: parsertest project, Window refresh issue, rev 7788
« Reply #15 on: February 16, 2012, 10:27:56 am »
Of course, I'm not, I don't follow their development.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #16 on: February 17, 2012, 05:44:48 am »
Looks like 2.8 branch still have this issue(I test a wx 2.8 dll build from 2.8 branch 2011-12-01 in xunxun's c::b release).

So, I will go direct to wx 2.9.3 release. Are there any tips, it looks like the wiki is not quite up to date: Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks

Search the forum reveals some discussion, as a summrary
1, install wx2.9.3 32bit windows installer
2, edit some setup.h/setup0.h files to disable: wxUSE_STC
3, use the command:
Code: [Select]
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release clean
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release

Any ideas?

PS: why USE_PROPGRID=1 ? we have a wxpropgrid target in codeblocks.cbp, do they conflict? 
Search the forum and it looks like "USE_PROPGRID=1" should be set to let us build wxsmith plugins, right?
« Last Edit: February 17, 2012, 05:53:15 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: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #17 on: February 17, 2012, 07:49:21 am »
It looks like building exchndl do not need libintl, see my fix below.

This was found when I try to build a c::b against wx2.9.3 with xunxun's gcc 4.6.3.
My bfd and iberty libraries are build from gdb, but I configured gdb with out international language support, so it does not build/install the libintl, this cause a build error in exchndl target, but tracking the build error message, I found that libintl is not necessory, instread the libz is need.

I just test the codeblocks.cbp, it should be fixed too.

Code: [Select]
Index: CodeBlocks_wx29.cbp
===================================================================
--- CodeBlocks_wx29.cbp (revision 7807)
+++ CodeBlocks_wx29.cbp (working copy)
@@ -19,7 +19,7 @@
  <Linker>
  <Add library="bfd" />
  <Add library="iberty" />
- <Add library="intl" />
+ <Add library="z" />
  <Add directory="base\exchndl\lib" />
  </Linker>
  </Target>
   

There are some other part in the file maybe should be fixed.
Code: [Select]
Index: E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h
===================================================================
--- E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h (revision 7807)
+++ E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h (working copy)
@@ -98,13 +98,13 @@
 #define F_DLL           (0x2000)
 
 /* Extra structure which is used in the optional header.  */
-#ifndef _WINNT_H
-typedef struct _IMAGE_DATA_DIRECTORY
-{
-  bfd_vma VirtualAddress;
-  long    Size;
-}  IMAGE_DATA_DIRECTORY;
-#endif
+//#ifndef _WINNT_H
+//typedef struct _IMAGE_DATA_DIRECTORY
+//{
+//  bfd_vma VirtualAddress;
+//  long    Size;
+//}  IMAGE_DATA_DIRECTORY;
+//#endif
 #define PE_EXPORT_TABLE 0
 #define PE_IMPORT_TABLE 1
 #define PE_RESOURCE_TABLE 2
Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).
 
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: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #18 on: February 23, 2012, 02:55:08 pm »
It looks like building exchndl do not need libintl, see my fix below.
Ping, any body can have some comments?
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9604
Re: parsertest project, Window refresh issue, rev 7788
« Reply #19 on: February 23, 2012, 03:22:33 pm »
Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).
What about other (especially older) compilers?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #20 on: February 23, 2012, 04:12:38 pm »
Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).
What about other (especially older) compilers?
Both tests: I use libz from mingw official sites zlib.
Test ONE:
I test the tdm gcc 4.6.1 sjlj, the compile stage passed, so it looks like those declaration does not need at least in tdm-gcc 4.6.1. As I know, tdm gcc use official Mingw API.  while xunxun's gcc 4.6.3 use mingw64 API.
but the link stage failed:
Code: [Select]

-------------- Clean: exchndl in Code::Blocks wx2.8.x ---------------

Cleaned "Code::Blocks wx2.8.x - exchndl"

-------------- Build: exchndl in Code::Blocks wx2.8.x ---------------

[ 50.0%] gcc.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE     -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Ibase\exchndl\include  -c E:\code\cb\cb_trunk\src\base\exchndl\exchndl.c -o .objs\base\exchndl\exchndl.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll -Lbase\exchndl\lib  .objs\base\exchndl\exchndl.o   -o devel\exchndl.dll  -lwxmsw28u -lbfd -liberty -lz
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(bfd.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(pe-i386.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(pei-i386.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(archive.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(elf.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
5 errors, 0 warnings (0 minutes, 1 seconds)

Here, my libiberty and libbfd is copied from gdb installation which is build from xunxun's 4.6.3. so it have some undefined reference in the link stage
As a conclusion, I guess it should be OK if the libbfd is build from tdm-gcc.

Test Two:
I test under loaden's gcc 4.4.5 release under 2010.10.12 (MinGW ALL 4.4.5 (binutils-2.20.1-2,make-3.82,mingwrt-3.18,w32api-3.15,pthreads2.8,iconv_1.13.1)), still failed in the link stage:

Code: [Select]
------------- Clean: exchndl in Code::Blocks wx2.8.x ---------------

Cleaned "Code::Blocks wx2.8.x - exchndl"

-------------- Build: exchndl in Code::Blocks wx2.8.x ---------------

[ 50.0%] gcc.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE     -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Ibase\exchndl\include  -c E:\code\cb\cb_trunk\src\base\exchndl\exchndl.c -o .objs\base\exchndl\exchndl.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll -Lbase\exchndl\lib  .objs\base\exchndl\exchndl.o   -o devel\exchndl.dll  -lwxmsw28u -lbfd -liberty -lz
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (18560) greater than or equal to .debug_abbrev size (1202).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(bfd.o):bfd.c:(.text+0x23): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (59072) greater than or equal to .debug_abbrev size (1388).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(pe-i386.o):pe-i386.c:(.text+0x10f3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (164188) greater than or equal to .debug_abbrev size (1420).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(pei-i386.o):pei-i386.c:(.text+0x13c3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (30800) greater than or equal to .debug_abbrev size (1265).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(archive.o):archive.c:(.text+0x313): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '0', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(archive.o):archive.c:(.text+0x2bba): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (242624) greater than or equal to .debug_abbrev size (1608).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(elf.o):elf.c:(.text+0x3e3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (328996) greater than or equal to .debug_abbrev size (1596).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(elflink.o):elflink.c:(.text+0x1e77): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (68096) greater than or equal to .debug_abbrev size (1028).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x6fab): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '1', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x6fc3): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '20039', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x75a3): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '8259', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x75bb): undefined reference to `__chkstk_ms'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
11 errors, 0 warnings (0 minutes, 1 seconds)

So, the reason is the same as tdm-gcc. The libbfd and libiberty should have the same gcc version used to build exchndl.dll.

The change in internal.h should be OK from my point.

Can some one test it? 
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: 5264
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: parsertest project, Window refresh issue, rev 7788
« Reply #21 on: March 07, 2012, 01:46:09 am »
Now you can try to find the correct commit and then produce a backport patch (if possible). :)
FYI:
I really find that patch, and it can easily back port to wx2.8.12, so the refresh issue is gone. :) :) :)

See:
Re: wx2.8.12, windows wxTextCtrl does not refresh itself correctly
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 xunxun

  • Almost regular
  • **
  • Posts: 187
Re: parsertest project, Window refresh issue, rev 7788
« Reply #22 on: March 10, 2012, 12:59:52 am »
Hope it can be backed port to wx2.8 branch
Regards,
xunxun