Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: ollydbg on September 27, 2015, 04:02:20 am

Title: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 04:02:20 am
Since the MinGW-Build GCC 5.2 is the only GCC which support large PCH files(see details in good news about gcc which support large pch (http://forums.codeblocks.org/index.php/topic,18568.msg140107.html#msg140107)), I would give it a try.

I have download the wxWidgets 3.0.2 release, and follow the steps described in wiki: Compiling wxWidgets 3.0.0 to develop Code::Blocks (MSW) - CodeBlocks (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_(MSW))

It fails in the first step when building wx3.0.2 with the following errors:

Code
...
ranlib ..\..\lib\gcc_dll\libwxscintilla.a
g++ -c -o gcc_mswudll\monodll_dummy.o  -O2 -mthreads  -DHAVE_W32API_H -D__WXMSW__   -DNDEBUG    -D_UNICODE  -I..\..\lib\gcc_dll\mswu -I..\..\include  -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL   -Wno-ctor-dtor-privacy  -fno-keep-inline-dllexport -MTgcc_mswudll\monodll_dummy.o -MFgcc_mswudll\monodll_dummy.o.d -MD -MP ../../src/common/dummy.cpp
g++ -c -o gcc_mswudll\monodll_any.o  -O2 -mthreads  -DHAVE_W32API_H -D__WXMSW__   -DNDEBUG    -D_UNICODE  -I..\..\lib\gcc_dll\mswu -I..\..\include  -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL   -Wno-ctor-dtor-privacy  -fno-keep-inline-dllexport -MTgcc_mswudll\monodll_any.o -MFgcc_mswudll\monodll_any.o.d -MD -MP ../../src/common/any.cpp
In file included from E:/code/gcc/i686-5.2.0-release-posix-dwarf-rt_v4-rev0/mingw32/i686-w64-mingw32/include/c++/type_traits:35:0,
                 from ..\..\include/wx/strvararg.h:25,
                 from ..\..\include/wx/string.h:46,
                 from ..\..\include/wx/any.h:19,
                 from ../../src/common/any.cpp:18:
E:/code/gcc/i686-5.2.0-release-posix-dwarf-rt_v4-rev0/mingw32/i686-w64-mingw32/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \
  ^
In file included from ..\..\include/wx/string.h:46:0,
                 from ..\..\include/wx/any.h:19,
                 from ../../src/common/any.cpp:18:
..\..\include/wx/strvararg.h:350:18: error: 'is_enum' in namespace 'std' does not name a template type
     typedef std::is_enum<T> is_enum;
                  ^
..\..\include/wx/strvararg.h:354:54: error: 'is_enum' was not declared in this scope
     enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
                                                      ^
..\..\include/wx/strvararg.h:354:68: error: template argument 1 is invalid
     enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
                                                                    ^
makefile.gcc:6428: recipe for target 'gcc_mswudll\monodll_any.o' failed
mingw32-make: *** [gcc_mswudll\monodll_any.o] Error 1

Do I need to enable the c++11 command line option? Any one has experience about building wx 3.0.2? Thanks.

BTW: It looks like c++11 option is not suggested, see: Trouble using wxWidgets 3.0.2 library under Mingw 64 (http://stackoverflow.com/questions/27285706/trouble-using-wxwidgets-3-0-2-library-under-mingw-64), instread, they suggest "gnu++11" option.

Thanks.

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 07:41:18 am
It looks like that this issue has discussed in wx user forum, see: https://groups.google.com/d/msg/wx-users/jZNzDXXnjCs/AQB3MB6HogEJ (https://groups.google.com/d/msg/wx-users/jZNzDXXnjCs/AQB3MB6HogEJ)

And the actual fix is in trunk: Don't attempt using <type_traits> with g++ 4.9.2 in C++98 mode. · wxWidgets/wxWidgets@4f846f7 (https://github.com/wxWidgets/wxWidgets/commit/4f846f72de795b86d8de0990dc3c340d30722a0e)

So, this patch need to be applied on the wxWidgets 3.0.2 release. :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 07:53:54 am
The patch file can be generated by adding a ".patch" in the URL, so here is the patch:

https://github.com/wxWidgets/wxWidgets/commit/4f846f72de.patch (https://github.com/wxWidgets/wxWidgets/commit/4f846f72de.patch)

EDIT: with this patch, I can successfully build wx 3.0.2 with gcc 5.2 by the method mentioned in wiki: Compiling wxWidgets 3.0.0 to develop Code::Blocks (MSW) - CodeBlocks (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_(MSW))

Now, I'm going to see if I can build CB against wx 3.0.2 with PCH enabled, see related discussion here: Re: Patches for Compiling Code::Blocks against wxWidgets 3.0 using MinGW GCC 4.8.1 (http://forums.codeblocks.org/index.php/topic,18568.msg140107.html#msg140107)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 09:10:55 am
OK, successfully build CodeBlocks_wx30.cbp with PCH enabled (under gcc 5.2).
I use my patch to build C::B against wx 3.0 with PCH enabled (http://forums.codeblocks.org/index.php/topic,18821.msg128936.html#msg128936) to CodeBlocks_wx30.cbp

Besides that, I have add an compiler option:
Code
-Wno-deprecated-declarations
to avoid a lot of warnings from wx.

Also, I see some warnings from C::B source:

Code
-------------- Build: sdk in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[  0.8%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c include\sdk_precomp.h -o .objs30\include\sdk_precomp.h.gch
In file included from include\cbauibook.h:13:0,
                 from include\sdk_common.h:133,
                 from include\sdk_precomp.h:13:
D:\wx3\include/wx/aui/auibook.h:349:18: warning: 'virtual bool wxAuiNotebook::AddPage(wxWindow*, const wxString&, bool, int)' was hidden [-Woverloaded-virtual]
     virtual bool AddPage(wxWindow *page, const wxString &text, bool select,
                  ^
In file included from include\sdk_common.h:133:0,
                 from include\sdk_precomp.h:13:
include\cbauibook.h:141:14: warning:   by 'bool cbAuiNotebook::AddPage(wxWindow*, const wxString&, bool, const wxBitmap&)' [-Woverloaded-virtual]
         bool AddPage(wxWindow* page,
              ^
In file included from include\cbauibook.h:13:0,
                 from include\sdk_common.h:133,
                 from include\sdk_precomp.h:13:
D:\wx3\include/wx/aui/auibook.h:352:18: warning: 'virtual bool wxAuiNotebook::InsertPage(size_t, wxWindow*, const wxString&, bool, int)' was hidden [-Woverloaded-virtual]
     virtual bool InsertPage(size_t index, wxWindow *page, const wxString &text,
                  ^
In file included from include\sdk_common.h:133:0,
                 from include\sdk_precomp.h:13:
include\cbauibook.h:156:14: warning:   by 'bool cbAuiNotebook::InsertPage(size_t, wxWindow*, const wxString&, bool, const wxBitmap&)' [-Woverloaded-virtual]
         bool InsertPage(size_t page_idx,
              ^

Maybe, we need to fix our C::B's source :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 09:18:08 am
After finishing building CodeBlocks_wx30.cbp and running update30.bat, I just start C::B inside C::B.
The first thing I see is a dialog from wx, says
Quote
15:23:36: Resource files must have same version number.
15:23:38: Resource files must have same version number.
I think I have reported some where in this forum, but it is lost...
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 11:07:22 am
I see crash when I exits C::B, or I enable or disable several plugins, but I can't catch them, all seems come from the wx core.

Code
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x6474c5e5 in wxWindow::FindItemByHWND(HWND__*, bool) const () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]>>>>>>cb_gdb:

Program received signal SIGSEGV, Segmentation fault.
In wxWindow::FindItemByHWND(HWND__*, bool) const () (D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll)

[debug]> bt 30
[debug]#0  0x6474c5e5 in wxWindow::FindItemByHWND(HWND__*, bool) const () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#1  0x6474dc28 in wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#2  0x6475911b in wxWindow::MSWHandleMessage(long*, unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#3  0x647497a0 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#4  0x64741f96 in wxTopLevelWindowMSW::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#5  0x647a8046 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#6  0x64751223 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#7  0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#8  0x001d0a82 in ?? ()
[debug]#9  0x00000133 in ?? ()
[debug]#10 0x86011c8a in ?? ()
[debug]#11 0x00140eb6 in ?? ()
[debug]#12 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#13 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#14 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#15 0x7e42927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll
[debug]#16 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 02:02:57 pm
Interesting, I got a crash call stack, which comes from debugger sdk, see:
Code
[debug]> bt 30
[debug]#0  0x6474c5e5 in wxWindow::FindItemByHWND(HWND__*, bool) const () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#1  0x6474dc28 in wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#2  0x6475911b in wxWindow::MSWHandleMessage(long*, unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#3  0x647497a0 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#4  0x64741f96 in wxTopLevelWindowMSW::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#5  0x647a8046 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#6  0x64751223 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#7  0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#8  0x001401da in ?? ()
[debug]#9  0x00000133 in ?? ()
[debug]#10 0xf3011d42 in ?? ()
[debug]#11 0x00410eea in BreakpointsDlg::OnOpen (this=0xffffffff, event=...) at F:\cb_sf_git\trunk\src\src\breakpointsdlg.cpp:338
[debug]#12 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#13 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from D:\wx3\lib\gcc_dll\wxmsw30u_gcc_cb.dll
[debug]#14 0x7e42927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll
[debug]#15 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:


This happens I try to enable the "open files list" plugin.


EDIT:
Debugged for a while, I found that the crash happens in this line: "m_pTree = new wxTreeCtrl..." in the source file plugins\openfileslist\openfileslistplugin.cpp around line 73.
Code
void OpenFilesListPlugin::OnAttach()
{
    m_ViewMenu = 0;

    m_EditorArray.Clear();

    // create tree
    m_pTree = new wxTreeCtrl(Manager::Get()->GetAppWindow(), idOpenFilesTree,wxDefaultPosition,wxSize(150, 100),
                            wxTR_HAS_BUTTONS | wxNO_BORDER | wxTR_HIDE_ROOT);

    // load bitmaps
    wxBitmap bmp;
    m_pImages = new wxImageList(16, 16);
    wxString prefix = ConfigManager::GetDataFolder() + _T("/images/");

    bmp = cbLoadBitmap(prefix + _T("folder_open.png"), wxBITMAP_TYPE_PNG); // folder
    m_pImages->Add(bmp);

    bmp = cbLoadBitmap(prefix + _T("ascii.png"), wxBITMAP_TYPE_PNG); // file
    m_pImages->Add(bmp);
    ...
Any one has the hint that why create a wxTreeCtrl get crashed?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 27, 2015, 02:44:01 pm
I will start testing this using GCC 5.2 from MSys2 and see if the results matches yours; I have no idea if the PCH bug is fixed in it. So, it will be one of the first things to test.

Edit: Are you doing 32 bit or 64 bit windows builds? I can test either one.

Tim S.

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 02:52:33 pm
Edit: Are you doing 32 bit or 64 bit windows builds? I can test either one.
I'm on an old 32 bit windows XP system. :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 27, 2015, 03:00:39 pm
Edit: Are you doing 32 bit or 64 bit windows builds? I can test either one.
I'm on an old 32 bit windows XP system. :)

I will be testing on Windows 7 (32 bit ?Ultra? or 64 bit Home Pro), likely start on 64 bit Home Pro first (Linux is Building something on the dual boot of the other one).

I will be doing it differently from you in the patch on Code::Blocks will NOT set WX_PRECOMP and no patch on wxWidgets if I can help doing that.

Edit:
gcc version 5.2.0 (Rev3, Built by MSYS2 project)
My GCC Compiler has this defined HAVE_TR1_TYPE_TRAITS
My GCC Compiler has this extra option -Wno-deprecated-declarations
My GCC Compiler has this additional path C:\Program Files\Git\cmd 
(I am building from a Git repo; I had a weird Git error till I added this path)


wxWidgets 3.0.2 was built with
CPPFLAGS="-DHAVE_TR1_TYPE_TRAITS"
CXXFLAGS="-fno-keep-inline-dllexport"


Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on September 27, 2015, 04:03:59 pm
My guess is that your build is totally broken.
Because this kind of backtrace can happen only if you right or double click in the breakpoints dialog.
So if you're not doing so and you're getting this, then your build is totally broken.
The cause might be mixing old and new dlls, broken compiler, pch problems, etc.

So if I were you I start with deleting everything in .objs30, devel30 and output30.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 04:14:04 pm
My guess is that your build is totally broken.
Because this kind of backtrace can happen only if you right or double click in the breakpoints dialog.
So if you're not doing so and you're getting this, then your build is totally broken.
The cause might be mixing old and new dlls, broken compiler, pch problems, etc.

So if I were you I start with deleting everything in .objs30, devel30 and output30.

But I did "deleting everything in .objs30, devel30 and output30." before I build the CodeBlocks_wx30.cbp.  :(
So, I see the build library should be cleaned.

I'm debugging on the crash issue, it happens randomly, some times, when I enable the plugin, it crashes at the call on the line "new wxTreeCtrl(...)", sometimes, it doesn't.

About the backtrace showing on
Code
[debug]#8  0x001401da in ?? ()
[debug]#9  0x00000133 in ?? ()
[debug]#10 0xf3011d42 in ?? ()
[debug]#11 0x00410eea in BreakpointsDlg::OnOpen (this=0xffffffff, event=...)
I think it is a gdb unwind issue, since there are many "?? ()" functions it can't unwinded.



Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 27, 2015, 04:37:14 pm
CB Projects that I did NOT add PCH back to and the reason why:
    Reason does NOT include sdk.h from inside source file (Header files do NOT count)
        DevPak
        ProjectOptionsManipulator
        Exporter
        Tools Plus Plugin
        wxWidgets - Contrib Items
        wxSmith
    Reason does NOT include sdk.h from inside source file before any other includes
        AutoVersioning
        Code Snippets
        KeyBinder
        SmartIndent
        NassiShneiderman
    Reason does NOT include sdk.h from inside source file (After #pragma implementation do NOT count)
        DragScroll
        KeyBinder
        MouseSap
    Reason includes sdk.h from inside header file.
        FileManager Plugin
    The bad reason did NOT wish to spend the time build wxSmith or wxWidgets - Contrib Items
        wxSmith - wxAUI
        wxSmith - Contrib Item

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 27, 2015, 04:50:33 pm
@Tim, did you see the crash issue? After building Codeblocks_wx30.cbp(no contributed plugins are needed), when you "disable" or "enable" the "open files list" plugin (all the other plugins are by default enabled), I always see the crash.

BTW: I can start the codeblocks from devel30 folder, but when I try to start codeblocks from output30 folder, I get an error dialog, which says "The application failed to initialize properly(0xc000007b). Click on OK to terminate the application.

I don't use the old configure files, because I use the CbLauncher.exe to launch the codeblocks, also I have totally clean the PATH, because I run CbLauncher.exe inside a bat file(this make the PATH environment clean), such as:
Code
@set PATH=E:\code\common_bin;D:\wx3\lib\gcc_dll;E:\code\gcc\i686-5.2.0-release-posix-dwarf-rt_v4-rev0\mingw32\bin
start cblauncher.exe --debug-log
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 27, 2015, 07:05:31 pm
I did NOT see the open files causing an issue when enable and then disable it.

The only plugins that started enabled was compiler and help.

I had to copy these DLLs from the MInGW bin folder to get CB to run from devel30_64 folder.
libgcc_s_seh-1.dll
libwinpthread-1.dll
libstdc++-6.dll


Edit: From output30_64 folder I get the same results.

NOTE: I have no MinGW installations in my system PATH variables because it caused issues in the past to me.

Edit2: Started CB from command prompt with path only set to output30_64 and still no issue
Started the second time this way with all core plugins enabled and some contrib plugs enabled and still no issue with enable and disable Open Files Plugin.
Code
cd C:\SourceCode\OpenSourceCode\Apps\IDEs\CodeBlocks\codeblocks_windows-git\src\output30_64
set path=C:\SourceCode\OpenSourceCode\Apps\IDEs\CodeBlocks\codeblocks_windows-git\src\output30_64
codeblocks


Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 01:01:58 am
Turns out that 32 bit MSys2 has only Mingw GCC 4.9.2; so, I downloaded the same mingw-builds as you and am trying to build wxWidgets.
It used to take two+ hours to build; but, something made my computer faster in the last few months.

Edit: My 32 bit MSys2 installation has problem; I think it likely that MinGW GCC 5.2 does exist for it.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 01:56:35 am
Here is the steps to reproduce the C::B crash issue with nightly build version from:The 26 September 2015 build (10503) is out. (http://forums.codeblocks.org/index.php/topic,20605.0.html)

1,  start c::b with PATH be empty. (only the home page window is opened, no project is opened)
2, open the plugin manager panel, suppose all plugins are enabled
3, disable the open files list plugin
4, enable the open files list plugin
5, close c::B  -> crash

This means the crash may not related to wx3, but wx2.8.12 also has the issue. The only difference is that under wx3, the crash happens in step 3 or step 4, but for wx2.8.12, the crash happens when closing c::b. I'm on WinXP 32 bit.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 03:10:15 am
Another crash issue I found is that it looks like my build c::B (against wx3) can't save the configure file correctly.

If I start C::B with those options: (the name "clean-configure" means I let C::B to create a "clean-configure.conf" file)
Code
-p clean-configure
Then when close C::B I get a crash, and actually no clean-configure.conf is saved.

Edit:
When running under GDB, I see a similar crash call stack inside the function FindItemByHWND()
Code
Program received signal SIGSEGV, Segmentation fault.
In wxWindow::FindItemByHWND(HWND__*, bool) const () (F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll)

[debug]> bt 30
[debug]#0  0x6474c5e5 in wxWindow::FindItemByHWND(HWND__*, bool) const () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#1  0x6474dc28 in wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#2  0x6475911b in wxWindow::MSWHandleMessage(long*, unsigned int, unsigned int, long) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#3  0x647497a0 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#4  0x64751223 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#5  0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#6  0x0004087e in ?? ()
[debug]#7  0x00000133 in ?? ()
[debug]#8  0x8601148d in ?? ()
[debug]#9  0x00070a62 in ?? ()
[debug]#10 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#11 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#12 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#13 0x7e42927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll
[debug]#14 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 04:44:43 am
Just noticed that the SVN I am using is 10474 and it did NOT have your problem.
Edit: This is using Git and it sometimes does NOT report the correct SVN under windows for me.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 09:54:42 am
Just noticed that the SVN I am using is 10474 and it did NOT have your problem.
Edit: This is using Git and it sometimes does NOT report the correct SVN under windows for me.

Tim S.
OK, but I'll wait to see the result from your result of 32 bit mingw gcc 5.2.  ;)

I'm consider whether it is cause by a broken GCC or it is broken by our C::B's source code....

Oh, I see a design flaw in the open files list plugin:
Code
void OpenFilesListPlugin::OnRelease(bool appShutDown)
{
    if (appShutDown)
        return;
    // remove registered event sinks
    Manager::Get()->RemoveAllEventSinksFor(this);

    // remove tree from docking system
    CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
    evt.pWindow = m_pTree;
    Manager::Get()->ProcessEvent(evt);

    // finally destroy the tree
    m_pTree->Destroy();
    m_pTree = nullptr;
}

Why do we need the two line:
Code
    if (appShutDown)
        return;
This means if we close the app, we don't need to destroy the resource allocated by this plugin?
Sounds like this will cause crashes in either wx2.8 or wx3 supported C::B.
I simply comment these two lines, and the good news is that I don't see the crash now for a simple test, I will do more tests to see whether there are other crashes.  EDIT: it still crashes.  :(
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 10:04:00 am
Well, I get confused about the document in cbplugin.h
Code
        /** Any descendent plugin should override this virtual method and
          * perform any necessary de-initialization. This method is called by
          * Code::Blocks (PluginManager actually) when the plugin has been
          * loaded, attached and should de-attach from Code::Blocks.\n
          * Think of this method as the actual destructor...
          * @param appShutDown If true, the application is shutting down. In this
          *         case *don't* use Manager::Get()->Get...() functions or the
          *         behaviour is undefined...
          */
        virtual void OnRelease(cb_optional bool appShutDown){}

I see many plugins are still using the Manager::Get()->Get...() in there OnRelease() function.
Such as:
Code
void CompilerGCC::OnRelease(bool appShutDown)
{
    // disable script functions
    ScriptBindings::gBuildLogId = -1;

    SaveOptions();
    Manager::Get()->GetConfigManager(_T("compiler"))->Write(_T("/default_compiler"), CompilerFactory::GetDefaultCompilerID());
    if (Manager::Get()->GetLogManager())
    {
        // for batch builds, the log is deleted by the manager
        if (!Manager::IsBatchBuild())
        {
            CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pLog);
            Manager::Get()->ProcessEvent(evt);
        }
        m_pLog = 0;

        CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pListLog);
        m_pListLog->DestroyControls();
        Manager::Get()->ProcessEvent(evt);
        m_pListLog = 0;
    }

    // let wx handle this on shutdown ( if we return here Valgrind will be sad :'( )
    if (!appShutDown)
        DoClearTargetMenu();

    m_timerIdleWakeUp.Stop();

    FreeProcesses();

    CompilerFactory::UnregisterCompilers();
}

or

Code
void DefaultMimeHandler::OnRelease(cb_unused bool appShutDown)
{
    CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
    evt.pWindow = m_Html;
    Manager::Get()->ProcessEvent(evt);
    m_Html->Destroy();
    m_Html = 0;

    // save configuration
    ConfigManager* conf = Manager::Get()->GetConfigManager(_T("mime_types"));
    wxArrayString list = conf->EnumerateKeys(_T("/"));
    for (unsigned int i = 0; i < list.GetCount(); ++i)
    {
        conf->UnSet(list[i]);
    }
    for (unsigned int i = 0; i < m_MimeTypes.GetCount(); ++i)
    {
        cbMimeType* mt = m_MimeTypes[i];
        wxString txt;
        txt << (mt->useEditor ? _T("true") : _T("false")) << _T(";");
        txt << (mt->useAssoc ? _T("true") : _T("false")) << _T(";");
        txt << (mt->programIsModal ? _T("true") : _T("false")) << _T(";");
        txt << mt->wildcard << _T(";");
        txt << mt->program << _T(' ');
        wxString key;
        key.Printf(_T("MimeType%u"), i);
        conf->Write(key, txt);
    }
    WX_CLEAR_ARRAY(m_MimeTypes);
}

Is the document wrong?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 11:36:55 am
Still did NOT see the problem; using SVN 10507 the prior one was likely 10506 reported wrong by Git.
I am using wx3.0.2 with no patches and the compiler is i686-5.2.0-release-posix-dwarf-rt_v4-rev0
This last time I used an SVN repo with all old stuff deleted.

Edit: I still had to copy 3 DLLs to get CB to run; if you did NOT then you did something very different from me.
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll


OS Windows 7 32 Bit Ultimate.

wxWidgets built with my new normal options of
CPPFLAGS="-DHAVE_TR1_TYPE_TRAITS"
CXXFLAGS="-Wno-unused-local-typedefs -fno-keep-inline-dllexport"

Tim S.

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 01:38:01 pm
Still did NOT see the problem; using SVN 10507 the last one was likely 10506 reported wrong by Git.
I am using wx3.0.2 with no patches and the compiler is i686-5.2.0-release-posix-dwarf-rt_v4-rev0
This last time I used an SVN repo with all old stuff deleted.
Thanks for the test.


Quote
Edit: I still had to copy 3 DLLs to get CB to run; if you did NOT then you did something very different from me.
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll
I did the same thing as you did.


Quote
OS Windows 7 32 Bit Ultimate.
This is the only difference(I'm on winXP 32bit), maybe, my OS is broken?  :(

Quote
wxWidgets built with my new normal options of
CPPFLAGS="-DHAVE_TR1_TYPE_TRAITS"
CXXFLAGS="-Wno-unused-local-typedefs -fno-keep-inline-dllexport"
I use different workaround to handle this issue, but I don't think this cause the crash issue.

EDIT: I still have the crash when enable or disable several plugins, and close the c::b.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 03:47:15 pm
I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:
Code
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-debug.txt 2>&1

Then I build C::B against this debug version of wx3 library.
By changing the codeblocks_30.cbp like below:
Code
 src/CodeBlocks_wx30.cbp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 2b6a679..43c4e9b 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -700,7 +700,7 @@
  </Target>
  <Environment>
  <Variable name="WX_CFG" value="" />
- <Variable name="WX_SUFFIX" value="u" />
+ <Variable name="WX_SUFFIX" value="ud" />
  <Variable name="WX_VERSION" value="30" />
  </Environment>
  </Build>
@@ -725,6 +725,7 @@
  <Add option="-DCB_PRECOMP" />
  <Add option="-DWX_PRECOMP" />
  <Add option="-DwxUSE_UNICODE" />
+ <Add option="-D__WXDEBUG__" />
  <Add directory="$(#WX30.include)" />
  <Add directory="$(#WX30.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
  <Add directory="sdk/wxscintilla/include" />

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine.  :)


EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 04:13:20 pm
I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine.  :)

I do NOT strip the DLLs put into output30 because no Compilers are in my path.

Do you still want the Zipped Binary of my CB build?

I am uploading it right now. I am guessing 30 minutes to finish uploading.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 04:17:30 pm
I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine.  :)

I do NOT strip the DLLs put into output30 because no Compilers are in my path.
I also have no Compilers in my PATH, but I have put an old "strip.exe" in my PATH.

Quote
Do you still want the Zipped Binary of my CB build?
I am uploading it right now. I am guessing 30 minutes to finish uploading.
Tim S.
Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 04:41:30 pm
Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.

PMed link to you.

Please confirm you received it; and it unzips good; I hope to delete that old location today.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: scarphin on September 28, 2015, 04:43:30 pm
EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.
I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 28, 2015, 04:58:36 pm
Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.

PMed link to you.

Please confirm you received it; and it unzips good; I hope to delete that old location today.

Tim S.

Hi, Tim, thanks.
I just tested your built version, and by enable and disable several plugins, I still see the crash.  :(
Here is the codeblocks.RPT:
Code
codeblocks.exe caused an Access Violation at location 69E8C5E5 in module wxmsw30u_gcc_mingw_builds.dll Reading from location 00000010.

Registers:
eax=6abc9220 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00040be8
eip=69e8c5e5 esp=0022d684 ebp=0a365f18 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

AddrPC   Params
69E8C5E5 00040BE8 00000001 00000016  wxmsw30u_gcc_mingw_builds.dll!wxWindow::FindItemByHWND(HWND__*, bool) const
69E8DC28 0022D830 00000133 4E01187C  wxmsw30u_gcc_mingw_builds.dll!wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*)
69E897A0 77F1E10B 0301112F 00000133  wxmsw30u_gcc_mingw_builds.dll!wxWindow::MSWWindowProc(unsigned int, unsigned int, long)

codeblocks.exe 13.12.0.0
ntdll.dll    5.1.2600.6055
kernel32.dll 5.1.2600.6532
COMCTL32.DLL 5.82.2900.6028
ADVAPI32.dll 5.1.2600.5755
RPCRT4.dll  5.1.2600.6477
Secur32.dll 5.1.2600.5834
GDI32.dll    5.1.2600.6460
USER32.dll  5.1.2600.5512
libgcc_s_dw2-1.dll
msvcrt.dll  7.0.2600.5512
libwinpthread-1.dll 1.0.0.0
SHELL32.dll 6.0.2900.6242
SHLWAPI.dll 6.0.2900.5912
SHFOLDER.DLL 6.0.2900.5512
libstdc++-6.dll
wxmsw30u_gcc_mingw_builds.dll 3.0.2.0
...
...
Which is much similar like the crash report I see in my self built C::B.
Thanks.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 28, 2015, 10:08:42 pm
New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.

Code
src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|
Line 70 to 72 below
Code
            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on September 29, 2015, 12:23:39 am
New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.

Code
src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|
Line 70 to 72 below
Code
            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }
Good catch, so it should be "if(sFnt.Len() == 0)", right?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on September 29, 2015, 02:46:01 am
New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.

Code
src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|
Line 70 to 72 below
Code
            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }
Good catch, so it should be "if(sFnt.Len() == 0)", right?

I had no idea; just thought the way it was looked very wrong.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 04, 2015, 09:55:29 am
First, I guess my Windows XP is broken, but I copy tim's built(which he build from win7) to another Windows XP computer, and I see the same crash there.

I build a wx3.0.2 release library which has debug information(has -g compiler option added)
Which shows some more detailed stack back trace, but still no idea where the crash come from:
 
Details are in a question I asked wx-user forum: help: wired crash issue which only happens in Windows XP system with release build of wx 3.0.2 (https://groups.google.com/forum/?fromgroups#!topic/wx-users/6sAlKVVpQiI).

While, the wx3.0.2 debug library works quite well(no crash here).

It looks like the bug are inside the Destroy() function of the whole GUI, which handling the AUI window. I have some test, if I put only two plugin dlls along with C::B, and in their OnAttach() function, I remove the code snippet:
Code
    CodeBlocksDockEvent evt(cbEVT_ADD_DOCK_WINDOW);
    ....
    Manager::Get()->ProcessEvent(evt);
Then, I don't see the crash.

Second issue is that OnRelease code, I see some code just do this:
Code
        // remove tree from docking system
        CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
        evt.pWindow = m_pTree;
        Manager::Get()->ProcessEvent(evt);

        // finally destroy the tree
        m_pTree->Destroy();
        m_pTree = nullptr;
But this is not correct, because if the function parameter "appShutDown" is true, the "Manager::Get()->ProcessEvent(evt)" just dose nothing.

Third issue
is how to remove the images created before the wxTree?
When in OnAttach(), we have:
Code
    m_pTree = new wxTreeCtrl();
    ...
    m_pImages = new wxImageList(16, 16);
    ....
    m_pTree->SetImageList(m_pImages);

But if the destroy of the wxTreeCtrl is done inside the Aui window system(as I said in second issue), what is the time to delete the m_pImages?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 04, 2015, 10:09:25 am
EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.
I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.
Currently, I would still suggest using -O0 option to build both wxWidgets 3.0.2 and C::B trunk, at least it don't crash on my windows XP.
Do you have a 32 bit C::B (include the wx 3.0.2 library)which you build with '-o3' option? If you don't have a Windows XP system, You can upload some where, and PM the link, I'd like to test it, thanks.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 04, 2015, 10:20:03 am
One thing I noticed when we build the "codeblocks.exe" (the target we named "src"), I see the "BUILDING_PLUGIN" is defined, this is much similar like building other plugin dlls. This enables the __declspec(dllexport) option.

Remove this "BUILDING_PLUGIN" is OK for the src target, but which cause the PCH file used for codeblocks.exe and other plugin dlls can't be shared. So, that's the reason we keep it there. :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 04, 2015, 11:52:12 am
One thing I forgot to mention is that switch between wx3.0.2 debug or release library is quite simple, you just need to change the link library name.

Code
 src/CodeBlocks_wx30.cbp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 61c6659..7b04c37 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -700,7 +700,7 @@
  </Target>
  <Environment>
  <Variable name="WX_CFG" value="" />
- <Variable name="WX_SUFFIX" value="u" />
+ <Variable name="WX_SUFFIX" value="ud" />
  <Variable name="WX_VERSION" value="30" />
  </Environment>

No need to add the "__WXDEBUG__" for the debug version, since both debug and release version of wxWidgets library have "__WXDEBUG__" defined.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 04, 2015, 01:24:26 pm
After finishing building CodeBlocks_wx30.cbp and running update30.bat, I just start C::B inside C::B.
The first thing I see is a dialog from wx, says
Quote
15:23:36: Resource files must have same version number.
15:23:38: Resource files must have same version number.
I think I have reported some where in this forum, but it is lost...
It is here: warning message about resource version number incorrect (http://forums.codeblocks.org/index.php/topic,20198.msg137722.html#msg137722), and the two warning above was caused by local patch files which does not belong to C::B trunk.  :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: MortenMacFly on October 04, 2015, 04:50:47 pm
Good catch, so it should be "if(sFnt.Len() == 0)", right?
Yes.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: MortenMacFly on October 04, 2015, 04:53:07 pm
It is here: warning message about resource version number incorrect (http://forums.codeblocks.org/index.php/topic,20198.msg137722.html#msg137722), and the two warning above was caused by local patch files which does not belong to C::B trunk.  :)
I've answered in the other thread.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: scarphin on October 04, 2015, 10:23:13 pm
I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.
Currently, I would still suggest using -O0 option to build both wxWidgets 3.0.2 and C::B trunk, at least it don't crash on my windows XP.
Do you have a 32 bit C::B (include the wx 3.0.2 library)which you build with '-o3' option? If you don't have a Windows XP system, You can upload some where, and PM the link, I'd like to test it, thanks.
Hmm, I think my comment caused a confusion, my apologies. I'm not using cb with wx3.0, I'm still using it with wx2.8. I just wanted to emphasize that using '-o3' doesn't make my build crash or behave abnormal in some way. It's just as stable as a normal nightly if not more. I also built wx2.8 with default release option, I think it is '-o2' and I didn't change it. Sorry for the confusion again. I'm very busy currently to make any wx3.0 build but I think I have a ready to use wx3.0 build so I may try building cb when and if I can find some time. Do you require an xp or a win7 build? I'll pm you a link if I success (again if I can find some time, no promises ;)). Lastly be aware I'm using mingw-builds compiler not tdm if that matters.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 05, 2015, 02:01:06 am
Do you have issue with CB locking up when you run ProjectOptionsManipulator wx3.0 compiled with gcc 5.2 under windows?
I am testing a modified version of SVN rev 10515 and once I try to bring up the ProjectOptionsManipulator CB stops responding.

wxWidgets 3.02
Windows 7 64 bit
MSys2 MinGW64 GCC 5.2 64 bit

Edit: I am going to try upgrading to a newer SVN rev to see if that fixes the problem.

Tim S.



 
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 05, 2015, 03:26:05 am
Do you have issue with CB locking up when you run ProjectOptionsManipulator wx3.0 compiled with gcc 5.2 under windows?
I am testing a modified version of SVN rev 10515 and once I try to bring up the ProjectOptionsManipulator CB stops responding.

wxWidgets 3.02
Windows 7 64 bit
MSys2 MinGW64 GCC 5.2 64 bit

Edit: I am going to try upgrading to a newer SVN rev to see if that fixes the problem.

Tim S.
I just build this plugin, and I can enable or disable this plugin in C::B's plugin manager, no crash here. I'm also using rev10515, wxWidgts and C::B are all build with "-O0".

EDIT: I can use this plugin to search something in a C::B project, works fine here. :)

EDIT2 I get wired compiler warnings which point to a "}" in the cpp file:
Code
-------------- Build: default in ProjectOptionsManipulator wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 25.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DwxUSE_UNICODE -I..\..\..\include -I..\..\..\sdk\wxscintilla\include -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -c ProjectOptionsManipulator.cpp -o ..\..\..\.objs30\plugins\contrib\ProjectOptionsManipulator\ProjectOptionsManipulator.o
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3683:22: note: declared here
         virtual bool TryValidator(wxEvent& WXUNUSED(event)), return false; )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
 #define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3682:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryParent(wxEvent&)' is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3686:22: note: declared here
         virtual bool TryParent(wxEvent& event), return DoTryApp(event); )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
 #define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3685:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
...
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 05, 2015, 03:36:03 am
...
Do you require an xp or a win7 build? I'll pm you a link if I success (again if I can find some time, no promises ;)). Lastly be aware I'm using mingw-builds compiler not tdm if that matters.
I mean if you build a 32 bit binary C::B, I can test it on my 32bit winXP. Thanks.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 05, 2015, 07:44:05 am
Hi, Tim, I just looked at the PCH relate topic, and I see that "WX_PRECOMP" is not needed in the codeblocks.cbp or codeblocks_w30.cbp, since we don't need a wx/wxprec.h in our C::B project, also we don't need to generate a single wxprec.h.gch. Since sdk.h already includes all the wx/xxx.h C::B needed, See our discussion here: patch to build C::B against wx 3.0 with PCH enabled (http://forums.codeblocks.org/index.php/topic,18821.msg128936.html#msg128936)

EDIT:
In the sdk_common.h, we have such code
Code
#if defined(NOPCH)
    #undef CB_PRECOMP
#endif // NOPCH

#if ( defined(CB_PRECOMP) && !defined(WX_PRECOMP) )
    #define WX_PRECOMP
#endif // CB_PRECOMP

// basic wxWidgets headers : this one itself will check for precompiled headers
// and if so will include a list of wx headers, at the bottom we add some more headers
// in the case of precompilation (note : some headers are in both lists)
// so even if NO CB_PRECOMP we can still have WX_PRECOMP turned on in this "wxprec" header
#include <wx/wxprec.h>

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#include "prep.h" // this is deliberately not inside the #ifdef block

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    #include <wx/choice.h>
    #include <wx/colordlg.h>
    #include <wx/combobox.h>
    #include <wx/confbase.h>
    #include <wx/datetime.h>
    #include <wx/dialog.h>
    #include <wx/dir.h>
    #include <wx/dynarray.h>
    #include <wx/event.h>
    #include <wx/file.h>
    #include <wx/filename.h>
    #include <wx/font.h>
    #include <wx/frame.h>
    #include <wx/fs_zip.h>
    #include <wx/hashmap.h>
    #include <wx/image.h>
    #include <wx/imaglist.h>
    #include <wx/intl.h>
    #include <wx/list.h>
    #include <wx/listbox.h>
    #include <wx/listctrl.h>
    #include <wx/log.h>
    #include <wx/menu.h>
    #include <wx/menuitem.h>
    #include <wx/msgdlg.h>
    #include <wx/notebook.h>
    #include <wx/panel.h>
    #include <wx/print.h>
    #include <wx/process.h>
    #include <wx/radiobox.h>
    #include <wx/radiobut.h>
    #include <wx/regex.h>
    #include <wx/sizer.h>
    #include <wx/socket.h>
    #include <wx/spinctrl.h>
    #include <wx/splitter.h>
    #include <wx/stattext.h>
    #include <wx/string.h>
    #include <wx/textctrl.h>
    #include <wx/thread.h>
    #include <wx/timer.h>
    #include <wx/toolbar.h>
    #include <wx/treectrl.h>
    #include <wx/txtstrm.h>
    #include <wx/utils.h>
    #include <wx/wfstream.h>
    #include <wx/wxscintilla.h>
    #include <wx/xrc/xmlres.h>

    // basic headers
    #include "settings.h"
    #include "globals.h"
    #include "sdk_events.h"
    #include "cbexception.h"

    // absolute base classes
    #include "logger.h"
    #include "editorbase.h"
    #include "cbeditor.h"
    #include "compileoptionsbase.h"
    #include "compiletargetbase.h"
    #include "projectbuildtarget.h"
    #include "projectfile.h"
    #include "cbplugin.h"
    #include "cbproject.h"
    #include "cbtool.h"
    #include "cbworkspace.h"
    #include "compilerfactory.h"
    #include "compiler.h"
    #include "workspaceloader.h"
    #include "editorcolourset.h"
    #include "pipedprocess.h"
    #include "scrollingdialog.h"
    #include "cbauibook.h"


    // managers
    #include "manager.h"
    #include "configmanager.h"
    #include "editormanager.h"
    #include "logmanager.h"
    #include "projectmanager.h"
    #include "menuitemsmanager.h"
    #include "scriptingmanager.h"
    #include "toolsmanager.h"
    #include "templatemanager.h"
    #include "macrosmanager.h"
    #include "pluginmanager.h"
    #include "personalitymanager.h"
    #include "uservarmanager.h"
    #include "filemanager.h"

    // other base files
    #include "xtra_res.h"
    #include "safedelete.h"
    #include "infowindow.h"
    #include "licenses.h"

#endif // CB_PRECOMP


So, if wx/wxprec.h contains some extra header files we don't needed. Such as the ones not in below #ifdef
Code
#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    ...

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 05, 2015, 12:46:52 pm
Hi, Tim, I just looked at the PCH relate topic, and I see that "WX_PRECOMP" is not needed in the codeblocks.cbp or codeblocks_w30.cbp, since we don't need a wx/wxprec.h in our C::B project, also we don't need to generate a single wxprec.h.gch. Since sdk.h already includes all the wx/xxx.h C::B needed, See our discussion here: patch to build C::B against wx 3.0 with PCH enabled (http://forums.codeblocks.org/index.php/topic,18821.msg128936.html#msg128936)

EDIT:
In the sdk_common.h, we have such code
Code
#if defined(NOPCH)
    #undef CB_PRECOMP
#endif // NOPCH

#if ( defined(CB_PRECOMP) && !defined(WX_PRECOMP) )
    #define WX_PRECOMP
#endif // CB_PRECOMP

// basic wxWidgets headers : this one itself will check for precompiled headers
// and if so will include a list of wx headers, at the bottom we add some more headers
// in the case of precompilation (note : some headers are in both lists)
// so even if NO CB_PRECOMP we can still have WX_PRECOMP turned on in this "wxprec" header
#include <wx/wxprec.h>

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#include "prep.h" // this is deliberately not inside the #ifdef block

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    #include <wx/choice.h>
    #include <wx/colordlg.h>
    #include <wx/combobox.h>
    #include <wx/confbase.h>
    #include <wx/datetime.h>
    #include <wx/dialog.h>
    #include <wx/dir.h>
    #include <wx/dynarray.h>
    #include <wx/event.h>
    #include <wx/file.h>
    #include <wx/filename.h>
    #include <wx/font.h>
    #include <wx/frame.h>
    #include <wx/fs_zip.h>
    #include <wx/hashmap.h>
    #include <wx/image.h>
    #include <wx/imaglist.h>
    #include <wx/intl.h>
    #include <wx/list.h>
    #include <wx/listbox.h>
    #include <wx/listctrl.h>
    #include <wx/log.h>
    #include <wx/menu.h>
    #include <wx/menuitem.h>
    #include <wx/msgdlg.h>
    #include <wx/notebook.h>
    #include <wx/panel.h>
    #include <wx/print.h>
    #include <wx/process.h>
    #include <wx/radiobox.h>
    #include <wx/radiobut.h>
    #include <wx/regex.h>
    #include <wx/sizer.h>
    #include <wx/socket.h>
    #include <wx/spinctrl.h>
    #include <wx/splitter.h>
    #include <wx/stattext.h>
    #include <wx/string.h>
    #include <wx/textctrl.h>
    #include <wx/thread.h>
    #include <wx/timer.h>
    #include <wx/toolbar.h>
    #include <wx/treectrl.h>
    #include <wx/txtstrm.h>
    #include <wx/utils.h>
    #include <wx/wfstream.h>
    #include <wx/wxscintilla.h>
    #include <wx/xrc/xmlres.h>

    // basic headers
    #include "settings.h"
    #include "globals.h"
    #include "sdk_events.h"
    #include "cbexception.h"

    // absolute base classes
    #include "logger.h"
    #include "editorbase.h"
    #include "cbeditor.h"
    #include "compileoptionsbase.h"
    #include "compiletargetbase.h"
    #include "projectbuildtarget.h"
    #include "projectfile.h"
    #include "cbplugin.h"
    #include "cbproject.h"
    #include "cbtool.h"
    #include "cbworkspace.h"
    #include "compilerfactory.h"
    #include "compiler.h"
    #include "workspaceloader.h"
    #include "editorcolourset.h"
    #include "pipedprocess.h"
    #include "scrollingdialog.h"
    #include "cbauibook.h"


    // managers
    #include "manager.h"
    #include "configmanager.h"
    #include "editormanager.h"
    #include "logmanager.h"
    #include "projectmanager.h"
    #include "menuitemsmanager.h"
    #include "scriptingmanager.h"
    #include "toolsmanager.h"
    #include "templatemanager.h"
    #include "macrosmanager.h"
    #include "pluginmanager.h"
    #include "personalitymanager.h"
    #include "uservarmanager.h"
    #include "filemanager.h"

    // other base files
    #include "xtra_res.h"
    #include "safedelete.h"
    #include "infowindow.h"
    #include "licenses.h"

#endif // CB_PRECOMP


So, if wx/wxprec.h contains some extra header files we don't needed. Such as the ones not in below #ifdef
Code
#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    ...

I agree that setting WX_PRECOMP in any cbp files is NOT needed or wanted. But, remember for Windows we still need both headers sdk.h and sdk_precomp.h (might have misspelled the second one).

Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.


Note: I have decided that "sdk" is more accurate than <sdk.h> because the PCH file is always a local project file and never a system header using MinGW GCC and likely all GCC are the same. Not, sure about other compilers.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 05, 2015, 01:03:57 pm
Do you have issue with CB locking up when you run ProjectOptionsManipulator wx3.0 compiled with gcc 5.2 under windows?
I am testing a modified version of SVN rev 10515 and once I try to bring up the ProjectOptionsManipulator CB stops responding.

wxWidgets 3.02
Windows 7 64 bit
MSys2 MinGW64 GCC 5.2 64 bit

Edit: I am going to try upgrading to a newer SVN rev to see if that fixes the problem.

Tim S.
I just build this plugin, and I can enable or disable this plugin in C::B's plugin manager, no crash here. I'm also using rev10515, wxWidgts and C::B are all build with "-O0".

EDIT: I can use this plugin to search something in a C::B project, works fine here. :)

EDIT2 I get wired compiler warnings which point to a "}" in the cpp file:
Code
-------------- Build: default in ProjectOptionsManipulator wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 25.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DwxUSE_UNICODE -I..\..\..\include -I..\..\..\sdk\wxscintilla\include -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -c ProjectOptionsManipulator.cpp -o ..\..\..\.objs30\plugins\contrib\ProjectOptionsManipulator\ProjectOptionsManipulator.o
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3683:22: note: declared here
         virtual bool TryValidator(wxEvent& WXUNUSED(event)), return false; )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
 #define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3682:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryParent(wxEvent&)' is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3686:22: note: declared here
         virtual bool TryParent(wxEvent& event), return DoTryApp(event); )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
 #define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3685:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
...

Thank you for the feedback; so, its likely a Windows 64 bit issue, MSys2 GCC, or security software on my PC.
I will try it using Windows 32bit and MSys GCC to see if that fixes the issues. (Already tried it without my patches and the problem still happened)

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 05, 2015, 04:30:46 pm
I agree that setting WX_PRECOMP in any cbp files is NOT needed or wanted. But, remember for Windows we still need both headers sdk.h and sdk_precomp.h (might have misspelled the second one).
Yes, there are still two gch files (sdk.h.gch and sdk_precomp.h.gch), and I think they are used to handle the __declspec (dllimport) and __declspec (dllexport) differences.
But do we really need that? WIN32 - ld (https://sourceware.org/binutils/docs-2.17/ld/WIN32.html) says that we don't need to specify those import or export attribute.

1, I see that when bulding the sdk, we already have an option: "-Wl,--export-all-symbols", from the above document, this means all the symbols will be exported (whenever the symbol have dllexport or not)
2, I see that all target(either sdk or src or other plugins) have "-Wl,--enable-auto-import", this means the "ld" can handle the symbol import quit well
3, maybe, we need to add another linker option: "--enable-runtime-pseudo-relocs" to handle the import issue, as also statement in the ld document.

I haven't tried it yet, It's great if we can keep only one pch file.




Quote
Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.
OK, I understand, currently it looks like we still need to put "wx/wx.h" or "wx/wxprec.h" in c::b headers. seePrecompiled Headers - WxWiki (https://wiki.wxwidgets.org/Precompiled_Headers)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: MortenMacFly on October 05, 2015, 06:33:07 pm
I agree that setting WX_PRECOMP in any cbp files is NOT needed or wanted. But, remember for Windows we still need both headers sdk.h and sdk_precomp.h (might have misspelled the second one).
Yes, there are still two gch files (sdk.h.gch and sdk_precomp.h.gch), and I think they are used to handle the __declspec (dllimport) and __declspec (dllexport) differences.
But do we really need that? WIN32 - ld (https://sourceware.org/binutils/docs-2.17/ld/WIN32.html) says that we don't need to specify those import or export attribute.

1, I see that when bulding the sdk, we already have an option: "-Wl,--export-all-symbols", from the above document, this means all the symbols will be exported (whenever the symbol have dllexport or not)
2, I see that all target(either sdk or src or other plugins) have "-Wl,--enable-auto-import", this means the "ld" can handle the symbol import quit well
3, maybe, we need to add another linker option: "--enable-runtime-pseudo-relocs" to handle the import issue, as also statement in the ld document.

I haven't tried it yet, It's great if we can keep only one pch file.




Quote
Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.
OK, I understand, currently it looks like we still need to put "wx/wx.h" or "wx/wxprec.h" in c::b headers. seePrecompiled Headers - WxWiki (https://wiki.wxwidgets.org/Precompiled_Headers)
If you want to do me a favour then please never use wx/wx.h at least. This is for the lazy bones that can't manage to properly include the minimal set of files really needed. I don't know why is there at all to be honest because it leads to bad behaviour.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 06, 2015, 01:44:20 am
Quote
Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.
OK, I understand, currently it looks like we still need to put "wx/wx.h" or "wx/wxprec.h" in c::b headers. seePrecompiled Headers - WxWiki (https://wiki.wxwidgets.org/Precompiled_Headers)

I read the stuff on the Link twice; I have no idea why you think it relates to this issue.
We in Code::Blocks under windows are never using a real PCH version of wxprec.h.
We do use a real PCH version of sdk.h and sdk_precomp.h; but, not as often as we should be.

Edit: I have already about a year ago removed the wxprec.h from sdk_common.h and I needed to add wx/defs.h as the first wx header in sdk_common.h. I then needed to fix about an dozen places building under Windows that resulted in compiling or linking errors.
Edit2: Remember to NOT define WX_PRECOMP in either the CB Projects or sdk_common.h.
Edit3: If you do NOT wish to fix the dozen places; you could just make a header based on wxprec.h from wx2.8 and wx3.0.
It would be a blend of the two headers; but, it would NOT include wx/wx.h and be included in sdk_common.h before including any wx headers.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 06, 2015, 02:46:12 am
Quote
Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.
OK, I understand, currently it looks like we still need to put "wx/wx.h" or "wx/wxprec.h" in c::b headers. seePrecompiled Headers - WxWiki (https://wiki.wxwidgets.org/Precompiled_Headers)

I read the stuff on the Link twice; I have no idea why you think it relates to this issue.
We in Code::Blocks under windows are never using a real PCH version of wxprec.h.
We do use a real PCH version of sdk.h and sdk_precomp.h; but, not as often as we should be.
I don't see it is an issue, what I mean is that wxprec.h may contains a lot of wx related headers(actually all the wx related headers are in wx.h included in wxprec.h) which we do not need in C::B, so we can directly include those wx related headers in C::B header. That's what you said below:
Quote
Edit: I have already about a year ago removed the wxprec.h from sdk_common.h and I needed to add wx/defs.h as the first wx header in sdk_common.h. I then needed to fix about an dozen places building under Windows that resulted in compiling or linking errors.
Edit2: Remember to NOT define WX_PRECOMP in either the CB Projects or sdk_common.h.
Edit3: If you do NOT wish to fix the dozen places; you could just make a header based on wxprec.h from wx2.8 and wx3.0.
It would be a blend of the two headers; but, it would NOT include wx/wx.h and be included in sdk_common.h before including any wx headers.

Tim S.
Agree, if we remove wxprec.h from sdk_common.h, we should also NOT put wx/wx.h in sdk_common.h.
EDIT: this is also said by Morten in his previous post.
But as you said, fix the dozen places may takes a lot of efforts, then the currently implementation (have wxprec.h in C::B header) is OK for me.  :)

Thanks.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 06, 2015, 02:54:32 am
Here is an example of the header to include in sdk_common.h in place of wxprec.h include.

Then there will only be 2 or 3 likely places to fix. Or we could just add the wx headers that we do NOT have in  sdk_common.h to that file. There is a wx header IIRC, the dnd.h header that will need added to sdk_common.h or included in the CB_PRECOMP headers list.

Code
/////////////////////////////////////////////////////////////////////////////
// Name:        wx_wrap_win_headers.h
// Purpose:     Includes the appropriate headers to avoid errors
//              Based on the wx/wxprec.h header created by Julian Smart
// Author:      Tim S.
// Modified by:
// Created:     2015-10-05
// Copyright:   (c) Julian Smart
// Licence:     wxWindows licence
/////////////////////////////////////////////////////////////////////////////

#ifndef WX_WRAP_WIN_HEADERS_H
#define WX_WRAP_WIN_HEADERS_H

#include <wx/defs.h>     // Multiple wx headers error out without this include before them.
#include <wx/version.h>  // Needed for wxCHECK_VERSION

// include the header that defines UNICODE macro correctly
// _before_ including <windows.h>
#if wxCHECK_VERSION(2, 9, 0)
#include <wx/chartype.h>
#else
#include <wx/wxchar.h>
#endif

// include standard Windows headers
#if defined(__WINDOWS__)
    #include <wx/msw/wrapwin.h>
    #include <wx/msw/private.h>
#endif
#if defined(__WXMSW__)
    #include <wx/msw/wrapcctl.h>
    #include <wx/msw/wrapcdlg.h>
    #include <wx/msw/missing.h>
#endif

#endif // WX_WRAP_WIN_HEADERS_H

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 06, 2015, 03:53:55 am
I agree that setting WX_PRECOMP in any cbp files is NOT needed or wanted. But, remember for Windows we still need both headers sdk.h and sdk_precomp.h (might have misspelled the second one).
Yes, there are still two gch files (sdk.h.gch and sdk_precomp.h.gch), and I think they are used to handle the __declspec (dllimport) and __declspec (dllexport) differences.
But do we really need that? WIN32 - ld (https://sourceware.org/binutils/docs-2.17/ld/WIN32.html) says that we don't need to specify those import or export attribute.

1, I see that when bulding the sdk, we already have an option: "-Wl,--export-all-symbols", from the above document, this means all the symbols will be exported (whenever the symbol have dllexport or not)
2, I see that all target(either sdk or src or other plugins) have "-Wl,--enable-auto-import", this means the "ld" can handle the symbol import quit well
3, maybe, we need to add another linker option: "--enable-runtime-pseudo-relocs" to handle the import issue, as also statement in the ld document.

I haven't tried it yet, It's great if we can keep only one pch file.

Some good news:
I was thinking to merge the two pch files to only one, here is the reference page I followed:
HOWTO Create and Deploy a Sample DLL using MinGW | MinGW (http://www.mingw.org/wiki/sampledll)
And I did the following:
1, example_dll.h, this file is modified from the one in above link, and add a #ifdef NOPORT, so that I can remove the __declspec kinds of decorations.
Code
#ifndef EXAMPLE_DLL_H
#define EXAMPLE_DLL_H

#ifdef __cplusplus
extern "C" {
#endif

#ifdef NOPORT
    #define EXAMPLE_DLL
#else
    #ifdef BUILDING_EXAMPLE_DLL
        #define EXAMPLE_DLL __declspec(dllexport)
    #else
        #define EXAMPLE_DLL __declspec(dllimport)
    #endif   
#endif

void __stdcall EXAMPLE_DLL hello(const char *s);

int EXAMPLE_DLL Double(int x);

#ifdef __cplusplus
}
#endif

// NOTE: this function is not declared extern "C"
void EXAMPLE_DLL CppFunc(void);

// NOTE: this class must not be declared extern "C"
class EXAMPLE_DLL MyClass
{
public:
        MyClass() {};
        virtual ~MyClass() {};
        void func(void);
};

#endif  // EXAMPLE_DLL_H

2, example_dll.cpp, which is copied from the above link:
Code
#include <stdio.h>
#include "example_dll.h"

__stdcall void hello(const char *s)
{
        printf("Hello %s\n", s);
}
int Double(int x)
{
        return 2 * x;
}
void CppFunc(void)
{
        puts("CppFunc");
}
void MyClass::func(void)
{
        puts("MyClass.func()");
}

3, example_exe.cpp, which is also copied from the above link:
Code
#include <stdio.h>
#include "example_dll.h"

int main(void)
{
        hello("World");
        printf("%d\n", Double(333));
        CppFunc();

        MyClass a;
        a.func();

        return 0;
}

4, the command I use to create the dll and the exe, and run the exe, I get the correct result
Code
D:\test\test-dll>g++ -c -DNOPORT example_dll.cpp

D:\test\test-dll>g++ -shared -o example_dll.dll example_dll.o -Wl,--export-all-symbols

D:\test\test-dll>g++ -c -DNOPORT example_exe.cpp

D:\test\test-dll>g++ -o example_exe.exe example_exe.o -L. -lexample_dll


D:\test\test-dll>example_exe.exe
Hello World
666
CppFunc
MyClass.func()

D:\test\test-dll>


5, Look at the two "g++ -c" command, I think it is a good place here that they can share a single PCH file, beecause they use the same compiler option.
I even don't use the "-no-undefined and --enable-runtime-pseudo-reloc" as stated in the link page.

EDIT:
The current dll(plugin) framework of C::B is just like the one I described in Plugin structure of C::B (http://wiki.codeblocks.org/index.php/Plugin_structure_of_C::B).
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 06, 2015, 04:17:11 am
OK, I can use a same PCH for either dll or exe, I just create a simple "sdk.h" file
Code
#ifndef SDK_H
#define SDK_H
#include <stdio.h>
#include "example_dll.h"
#endif // SDK_H
Then, I put the statement
Code
#include "sdk.h"
at the every beginning of the cpp files. (you can remove the old #incude statements in the cpp file)

Here is the result:
Code
D:\test\test-dll>g++ -c -DNOPORT sdk.h

D:\test\test-dll>g++ -c -DNOPORT example_dll.cpp -Winvalid-pch -include sdk.h

D:\test\test-dll>g++ -shared -o example_dll.dll example_dll.o -Wl,--export-all-symbols

D:\test\test-dll>g++ -c -DNOPORT example_dll.cpp -Winvalid-pch -include sdk.h

D:\test\test-dll>g++ -o example_exe.exe example_exe.o -L. -lexample_dll

D:\test\test-dll>example_exe.exe
Hello World
666
CppFunc
MyClass.func()
D:\test\test-dll>dir
 Volume in drive D has no label.
 Volume Serial Number is 0006-7EF2

 Directory of D:\test\test-dll

2015-10-06  10:23    <DIR>          .
2015-10-06  10:23    <DIR>          ..
2015-09-27  09:52                89 env.bat
2015-10-06  10:16               260 example_dll.cpp
2015-10-06  10:23            41,773 example_dll.dll
2015-10-06  09:44               718 example_dll.h
2015-10-06  10:23             1,157 example_dll.o
2015-10-06  10:16               185 example_exe.cpp
2015-10-06  10:23            50,196 example_exe.exe
2015-10-06  09:48             3,197 example_exe.o
2015-10-06  10:17                91 sdk.h
2015-10-06  10:20         1,577,668 sdk.h.gch
              10 File(s)      1,675,334 bytes
               2 Dir(s)  23,734,190,080 bytes free

D:\test\test-dll>

Look, one single pch file.  ;)


Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 06, 2015, 04:44:25 am
Now, I did some test in codeblocks_wx30.cbp
1, I remove the "src\.objs30\include\sdk.h.gch", so the folder only contains "sdk_precomp.h.gch", note that the first one was create when we build the src target(codeblocks.exe), and the later one is generated when we build the sdk target(codeblocks.dll).

2, select the "sdk.h" from the project manager panel, and right click to open the "property" dialog, and uncheck the "compile file" option.

3, copy the build option from sdk to src, that is: remove the "BUILDING_PLUGIN", and add those:
Code
EXPORT_LIB
EXPORT_EVENTS
WXMAKINGDLL_SCI

4, rebuild the target src(codeblocks.exe), and I see it build successfully, great! This means both the codeblocks.exe and codeblocks.dll now share the same pch file "sdk_precomp.h.gch".

I will see I can built any plugin dll later. :)


EDIT:

Good, with the same change to other C::B plugin target, I can also build them successfully, also the build C::B runs OK.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 06, 2015, 10:28:16 am
Here is one issue I see that the icon shows badly in wx 3.0.2 based C::B compared with wx 2.8 based.
See the image show below(the left is wx 3.0.2 based)
(http://imagizer.imageshack.us/v2/327x524q90/903/Fs5ita.png)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 06, 2015, 04:56:40 pm
Now, I did some test in codeblocks_wx30.cbp
1, I remove the "src\.objs30\include\sdk.h.gch", so the folder only contains "sdk_precomp.h.gch", note that the first one was create when we build the src target(codeblocks.exe), and the later one is generated when we build the sdk target(codeblocks.dll).

2, select the "sdk.h" from the project manager panel, and right click to open the "property" dialog, and uncheck the "compile file" option.

3, copy the build option from sdk to src, that is: remove the "BUILDING_PLUGIN", and add those:
Code
EXPORT_LIB
EXPORT_EVENTS
WXMAKINGDLL_SCI

4, rebuild the target src(codeblocks.exe), and I see it build successfully, great! This means both the codeblocks.exe and codeblocks.dll now share the same pch file "sdk_precomp.h.gch".

I will see I can built any plugin dll later. :)


EDIT:

Good, with the same change to other C::B plugin target, I can also build them successfully, also the build C::B runs OK.

1. Did you make sure the warning "-Winvalid-pch" is set?
2. Is the include of the PCH the first include in the file?
3. Is the path to the PCH header include before the NON PCH version of the header.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 07, 2015, 12:37:35 am
1. Did you make sure the warning "-Winvalid-pch" is set?
Yes, this option is on the project level.

Quote
2. Is the include of the PCH the first include in the file?
3. Is the path to the PCH header include before the NON PCH version of the header.
I think I have made some mistakes, it looks like the "non pch version of the header file" is used here, but "-Winvalid-pch" never show a warning about this, I will look into it.
Thanks.

EDIT normally the plugins and the src target need the file named "sdk.h", since there is no such "sdk.h.gch", then the original header file is used instead. :(
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 07, 2015, 01:30:00 am
Hi, Tim, the problem can be solved.
I just read the document page: Precompiled Headers - Using the GNU Compiler Collection (GCC) (https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html)
And this is what I did:

1, in my ".objs30\include" folder, I have two files
sdk_precomp.h.gch, this is the pch file generated when building the sdk target.
I create another one in this folder, named: sdk_precomp.h, and it has the contents:
Code
#error "non pch file is used!!!"
So, if the original "sdk_precomp.h" is used, the compiler will show an error.

2, this is my modified "include\sdk.h"
Code
/*
 * This file is part of the Code::Blocks IDE and licensed under the GNU Lesser General Public License, version 3
 * http://www.gnu.org/licenses/lgpl-3.0.html
 */

/** Code::Blocks SDK precompiled headers support for plugins.
  * This is precompiled with -DBUILDING_PLUGIN
  */

#ifndef SDK_H
#define SDK_H

//#ifdef __WXMSW__
// #include "sdk_common.h"
//#else
// for non-windows platforms, one PCH is enough
#include "sdk_precomp.h"
//#endif

#endif // SDK_H
Thus, I will let the "sdk.h" include "sdk_precomp.h".

3, simply do the previous two step doesn't solve the issue. As the document said:
Quote
A precompiled header can't be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you cannot include a precompiled header from inside another header.
The strange thing is: if I move the "sdk_precomp.h.gch" from the ".objs30/include" folder, and leave the dummy "sdk_precomp.h" in that folder, then rebuild a plugin, I see the build success. I think it should report an error from the dummy header.
Code
-------------- Clean: Autosave in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

Cleaned "Code::Blocks wx3.0.x - Autosave"

-------------- Build: Autosave in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -c plugins\autosave\autosave.cpp -o .objs30\plugins\autosave\autosave.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LD:\wx3\lib\gcc_dll -Ldevel30 .objs30\plugins\autosave\autosave.o  -o devel30\share\CodeBlocks\plugins\autosave.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined -mthreads  -lcodeblocks -lwxmsw30ud
Output file is devel30\share\CodeBlocks\plugins\autosave.dll with size 798.93 KB
[ 50.0%] Running target post-build steps
[100.0%] cmd /c if not exist devel30\share\CodeBlocks mkdir devel30\share\CodeBlocks
zip -jq9 devel30\share\CodeBlocks\autosave.zip plugins\autosave\manifest.xml plugins\autosave\*.xrc
Process terminated with status 0 (0 minute(s), 6 second(s))
0 error(s), 0 warning(s) (0 minute(s), 6 second(s))

Then, I try to use another method mention in gcc document, that is the "-include" command(this is the command to force include a header file firstly even there is no #include "xxx.h" statement in translation file), so I add on for this plugin in the compiler option:
Code
-include "sdk_precomp.h"
Now, I get the good result:
Code
-------------- Clean: Autosave in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

Cleaned "Code::Blocks wx3.0.x - Autosave"

-------------- Build: Autosave in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -include "sdk_precomp.h" -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -c plugins\autosave\autosave.cpp -o .objs30\plugins\autosave\autosave.o
In file included from <command-line>:0:0:
.objs30\include/sdk_precomp.h:1:2: error: #error "non pch file is used!!!"
 #error "non pch file is used!!!"
  ^
Process terminated with status 1 (0 minute(s), 4 second(s))
1 error(s), 0 warning(s) (0 minute(s), 4 second(s))
That means the compiler try to read the dummy header. (here, I still have only this dummy header file in the ".objs30/include")
Then, I place the "sdk_precomp.h.gch" back to the folder, and hit the "build" button gain, now, I see no #error report.
Code
-------------- Build: Autosave in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -include "sdk_precomp.h" -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -c plugins\autosave\autosave.cpp -o .objs30\plugins\autosave\autosave.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LD:\wx3\lib\gcc_dll -Ldevel30 .objs30\plugins\autosave\autosave.o  -o devel30\share\CodeBlocks\plugins\autosave.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined -mthreads  -lcodeblocks -lwxmsw30ud
Output file is devel30\share\CodeBlocks\plugins\autosave.dll with size 798.93 KB
[ 50.0%] Running target post-build steps
[100.0%] cmd /c if not exist devel30\share\CodeBlocks mkdir devel30\share\CodeBlocks
zip -jq9 devel30\share\CodeBlocks\autosave.zip plugins\autosave\manifest.xml plugins\autosave\*.xrc
Process terminated with status 0 (0 minute(s), 2 second(s))
0 error(s), 0 warning(s) (0 minute(s), 2 second(s))
Thus, "sdk_precomp.h.gch" is now truly used by the sdk and other plugin targets.  :)


Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 07, 2015, 01:45:50 am
Well, I looked at the codeblocks-unix.cbp:
Code
		<Unit filename="include/sdk.h">
<Option compile="1" />
<Option weight="1" />
<Option target="sdk" />
</Unit>
<Unit filename="include/sdk_common.h">
<Option target="sdk" />
</Unit>
<Unit filename="include/sdk_events.h">
<Option target="sdk" />
</Unit>
<Unit filename="include/sdk_precomp.h">
<Option compile="1" />
<Option weight="0" />
<Option target="sdk" />
</Unit>
This means under Linux, we also have two pch files generated? (both are from the sdk target, not the same with windows, under windows, pch of sdk.h is generated in src target)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 07, 2015, 04:05:52 pm
FYI: In Windows MinGW GCC a PCH only works inside of a real source file (headers files do NOT count).
In other words, a header can never include a real PCH file.

Edit: If on the command line you include a real PCH file like doing [-incude "sdk.h"] you will get a error normally if a header file in the project also includes that same PCH header of  "sdk.h"; it a weird error message that I forgot what it says.

Edit2: You will have to put guards around the includes inside some source files around includes of the PCH; never tried the guards around the includes in header files since they needed to be removed I just removed them. 

Tim S.
 
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 07, 2015, 10:40:55 pm
FYI: In Windows MinGW GCC a PCH only works inside of a real source file (headers files do NOT count).
In other words, a header can never include a real PCH file.

Edit: If on the command line you include a real PCH file like doing [-incude "sdk.h"] you will get a error normally if a header file in the project also includes that same PCH header of  "sdk.h"; it a weird error message that I forgot what it says.
I didn't see the weird error till now.  :)

Quote
Edit2: You will have to put guards around the includes inside some source files around includes of the PCH; never tried the guards around the includes in header files since they needed to be removed I just removed them. 
Tim S.
As I said, the modified "sdk.h" I use was like below:
Code
#ifndef SDK_H
#define SDK_H
#include "sdk_precomp.h"
#endif // SDK_H
Do you mean, I should wrote something like:
Code
#ifndef SDK_H
#define SDK_H
#ifndef SDK_PRECOMP_H
#include "sdk_precomp.h"
#endif
#endif // SDK_H

Ideally, if we share a single pch file for all dlls and exes, we need only one header file(which is included in source files for all sdk, dll targets), such as "sdk.h", "sdk_precomp.h" is not needed here.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 08, 2015, 02:41:34 pm
FYI: In Windows MinGW GCC a PCH only works inside of a real source file (headers files do NOT count).
In other words, a header can never include a real PCH file.

Edit: If on the command line you include a real PCH file like doing [-incude "sdk.h"] you will get a error normally if a header file in the project also includes that same PCH header of  "sdk.h"; it a weird error message that I forgot what it says.
I didn't see the weird error till now.  :)

Quote
Edit2: You will have to put guards around the includes inside some source files around includes of the PCH; never tried the guards around the includes in header files since they needed to be removed I just removed them. 
Tim S.
As I said, the modified "sdk.h" I use was like below:
Code
#ifndef SDK_H
#define SDK_H
#include "sdk_precomp.h"
#endif // SDK_H
Do you mean, I should wrote something like:
Code
#ifndef SDK_H
#define SDK_H
#ifndef SDK_PRECOMP_H
#include "sdk_precomp.h"
#endif
#endif // SDK_H

Ideally, if we share a single pch file for all dlls and exes, we need only one header file(which is included in source files for all sdk, dll targets), such as "sdk.h", "sdk_precomp.h" is not needed here.

I mean you have to put guards in every source file the includes the "sdk.h" (if that is the PCH file) and you are including it on the command line using [-include "sdk.h"]. Or you can removed every include of the PCH file from inside the source files and header files.

Edit: As I have already mentioned; but, it appears you missed it. Using [-include "sdk.h"] when sdk.h is NOT a PCH file is a waste of time because if it is NOT a PCH file it will compile slower that if it was NOT used as an option.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 08, 2015, 04:46:05 pm
Hi, Tim, I am using "-include "sdk_precomp.h"", not using "-include "sdk.h"", since I have only one pch file named "sdk_precomp.h.gch".
Sent from my phone.(sorry I cannot enter too much words)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 08, 2015, 07:51:00 pm
Hi, Tim, I am using "-include "sdk_precomp.h"", not using "-include "sdk.h"", since I have only one pch file named "sdk_precomp.h.gch".
Sent from my phone.(sorry I cannot enter too much words)

Good, that means you will only need to fix the code in the SDK folders instead of all the plugins.
I might try doing the same and see what errors I get when I have the time and energy.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 09, 2015, 06:11:56 am
Hi, Tim, I am using "-include "sdk_precomp.h"", not using "-include "sdk.h"", since I have only one pch file named "sdk_precomp.h.gch".
Sent from my phone.(sorry I cannot enter too much words)

Good, that means you will only need to fix the code in the SDK folders instead of all the plugins.
I might try doing the same and see what errors I get when I have the time and energy.

Tim S.

Glad to hear, and this is the patch I made to use single PCH files. Please note that if you use a release version of wxWidgets 3, you do not need to change the Variable WX_SUFFIX from u to ud.

Code
 src/CodeBlocks_wx30.cbp | 83 +++++++++++++++++++++++++++++++++++++++----------
 src/include/sdk.h       |  8 ++---
 2 files changed, 70 insertions(+), 21 deletions(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 3f63122..ac09ab1 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -168,7 +168,10 @@
  <Option parameters="--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug" />
  <Option projectLinkerOptionsRelation="2" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/scripting/include" />
  <Add directory="include/scripting/sqplus" />
@@ -226,7 +229,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/scripting/include" />
  <Add directory="include/scripting/sqplus" />
@@ -260,7 +266,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add option="-DASTYLE_LIB" />
  <Add directory="include" />
  <Add directory="plugins/astyle/astyle" />
@@ -293,7 +302,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -338,7 +350,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="plugins/compilergcc/depslib/src" />
  <Add directory="include/scripting/include" />
@@ -377,7 +392,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/scripting/include" />
  <Add directory="include/scripting/sqplus" />
@@ -410,7 +428,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add option="-DCC_NO_COLLAPSE_ITEM" />
  <Add directory="include" />
  <Add directory="include/mozilla_chardet" />
@@ -448,7 +469,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -479,7 +503,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -510,7 +537,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -541,7 +571,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -572,7 +605,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/mozilla_chardet" />
  <Add directory="include/mozilla_chardet/mfbt" />
@@ -609,7 +645,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/scripting/include" />
  <Add directory="include/scripting/sqplus" />
@@ -642,7 +681,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  <Add directory="include/mozilla_chardet" />
  <Add directory="include/mozilla_chardet/mfbt" />
@@ -679,7 +721,10 @@
  <Option run_host_application_in_terminal="0" />
  <Option projectLinkerOptionsRelation="1" />
  <Compiler>
- <Add option="-DBUILDING_PLUGIN" />
+ <Add option='-include &quot;sdk_precomp.h&quot;' />
+ <Add option="-DEXPORT_LIB" />
+ <Add option="-DEXPORT_EVENTS" />
+ <Add option="-DWXMAKINGDLL_SCI" />
  <Add directory="include" />
  </Compiler>
  <Linker>
@@ -700,7 +745,7 @@
  </Target>
  <Environment>
  <Variable name="WX_CFG" value="" />
- <Variable name="WX_SUFFIX" value="u" />
+ <Variable name="WX_SUFFIX" value="ud" />
  <Variable name="WX_VERSION" value="30" />
  </Environment>
  </Build>
@@ -716,11 +761,14 @@
  <Add option="-mthreads" />
  <Add option="-fmessage-length=0" />
  <Add option="-fexceptions" />
+ <Add option="-Winvalid-pch" />
+ <Add option="-Wno-deprecated-declarations" />
  <Add option="-DHAVE_W32API_H" />
  <Add option="-D__WXMSW__" />
  <Add option="-DWXUSINGDLL" />
  <Add option="-DcbDEBUG" />
- <Add option="-DNOPCH" />
+ <Add option="-DCB_PRECOMP" />
+ <Add option="-DWX_PRECOMP" />
  <Add option="-DwxUSE_UNICODE" />
  <Add directory="$(#WX30.include)" />
  <Add directory="$(#WX30.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
@@ -1272,6 +1320,7 @@
  <Option target="sdk" />
  </Unit>
  <Unit filename="include/sdk_precomp.h">
+ <Option compile="1" />
  <Option weight="0" />
  <Option target="sdk" />
  </Unit>
diff --git a/src/include/sdk.h b/src/include/sdk.h
index 46361c7..bfff9f6 100644
--- a/src/include/sdk.h
+++ b/src/include/sdk.h
@@ -10,11 +10,11 @@
 #ifndef SDK_H
 #define SDK_H
 
-#ifdef __WXMSW__
- #include "sdk_common.h"
-#else
+//#ifdef __WXMSW__
+// #include "sdk_common.h"
+//#else
  // for non-windows platforms, one PCH is enough
  #include "sdk_precomp.h"
-#endif
+//#endif
 
 #endif // SDK_H

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 11, 2015, 06:09:15 pm
I am NOT going to use your patch; because the CBP changes is too complex for what I think you are trying to do.

I think the use of "-Wl,--export-all-symbols" is a bad idea; but, it does have tradeoffs that are worth trying.
So, I am going to make a patch that does what I think you wish to do; and you can look at it and test it.

The bad effects that I think go along with using "-Wl,--export-all-symbols" are:
1. It can increase code coupling by accident. It can result is code you wish to be private/protected being more exposed.
2. It increases the size of the DLL file.
3. It likely results in greater ABI changes than are needed.

The good effect
1. It can make it simpler to make windows DLL.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 12, 2015, 06:35:31 am
I am NOT going to use your patch; because the CBP changes is too complex for what I think you are trying to do.

I think the use of "-Wl,--export-all-symbols" is a bad idea; but, it does have tradeoffs that are worth trying.
So, I am going to make a patch that does what I think you wish to do; and you can look at it and test it.

The bad effects that I think go along with using "-Wl,--export-all-symbols" are:
1. It can increase code coupling by accident. It can result is code you wish to be private/protected being more exposed.
2. It increases the size of the DLL file.
3. It likely results in greater ABI changes than are needed.

The good effect
1. It can make it simpler to make windows DLL.

Tim S.
Yes, I agree, if all the symbols which need to be exported are marked as "__declspec(dllexport)", we can safely remove the "-Wl,--export-all-symbols" linker option.

BTW: with my patch, I see the built exe and plugin dlls are slightly a little bigger, because I see more functions were in their exported symbol.

I'm looking forward to see your patch.  :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 12, 2015, 04:49:34 pm
I just did some test, if I remove the "-Wl,--export-all-symbols" option in the SDK target, after build the codeblocks.dll, I try to build the src target, but I get a lot of link errors, it looks like there are many classes which need to add "__declspec(dllexport)" decoration.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 12, 2015, 08:57:55 pm
What are the link errors and why does it work with 2.8?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 13, 2015, 01:24:47 am
What are the link errors and why does it work with 2.8?
1, undefined reference to some symbol name.
2, codeblocks.cbp ( for wx2.8 ) has the same "-Wl,--export-all-symbols" in its sdk target.

EDIT: my changes:
Code
 src/CodeBlocks_wx30.cbp        | 1 -
 src/include/cbexception.h      | 2 +-
 src/include/cbstyledtextctrl.h | 2 +-
 src/include/editorcolourset.h  | 2 +-
 src/include/filemanager.h      | 4 ++--
 src/include/manager.h          | 2 +-
 src/include/scrollingdialog.h  | 2 +-
 src/include/xtra_res.h         | 4 ++--
 src/sdk/scrollingdialog.cpp    | 3 ++-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index ac09ab1..5a304dd 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -136,7 +136,6 @@
  </Compiler>
  <Linker>
  <Add option="-Wl,--enable-auto-image-base" />
- <Add option="-Wl,--export-all-symbols" />
  <Add option="-Wl,--add-stdcall-alias" />
  <Add option="-Wl,--enable-auto-import" />
  <Add option="-Wl,--no-undefined" />
diff --git a/src/include/cbexception.h b/src/include/cbexception.h
index 2044dd9..bfa91bc 100644
--- a/src/include/cbexception.h
+++ b/src/include/cbexception.h
@@ -20,7 +20,7 @@ cbThrow() and cbAssert().
 */
 
 /** @brief The base Code::Blocks exception object. */
-class cbException
+class DLLIMPORT cbException
 {
     public:
         cbException(const wxString& msg, const wxString& file, int line);
diff --git a/src/include/cbstyledtextctrl.h b/src/include/cbstyledtextctrl.h
index 55835a3..77c3d78 100644
--- a/src/include/cbstyledtextctrl.h
+++ b/src/include/cbstyledtextctrl.h
@@ -17,7 +17,7 @@ class wxFocusEvent;
 class wxMouseEvent;
 class wxPoint;
 
-class cbStyledTextCtrl : public wxScintilla
+class DLLIMPORT cbStyledTextCtrl : public wxScintilla
 {
     public:
         cbStyledTextCtrl(wxWindow* pParent, int id, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0);
diff --git a/src/include/editorcolourset.h b/src/include/editorcolourset.h
index a6573bd..e79ddac 100644
--- a/src/include/editorcolourset.h
+++ b/src/include/editorcolourset.h
@@ -73,7 +73,7 @@ struct OptionSet
 };
 WX_DECLARE_STRING_HASH_MAP(OptionSet, OptionSetsMap);
 
-class EditorColourSet
+class DLLIMPORT EditorColourSet
 {
     public:
         EditorColourSet(const wxString& setName = COLORSET_DEFAULT);
diff --git a/src/include/filemanager.h b/src/include/filemanager.h
index 343c087..6d80f04 100644
--- a/src/include/filemanager.h
+++ b/src/include/filemanager.h
@@ -28,7 +28,7 @@ namespace TinyXML{ bool SaveDocument(const wxString&, TiXmlDocument*); }
 
 
 // ***** class: LoaderBase *****
-class LoaderBase : public AbstractJob
+class DLLIMPORT LoaderBase : public AbstractJob
 {
     wxSemaphore sem;
     bool wait;
@@ -109,7 +109,7 @@ public:
 };
 
 // ***** class: FileManager *****
-class FileManager : public Mgr<FileManager>
+class DLLIMPORT FileManager : public Mgr<FileManager>
 {
     BackgroundThread fileLoaderThread;
     BackgroundThread uncLoaderThread;
diff --git a/src/include/manager.h b/src/include/manager.h
index 7dfe827..cd0cb30 100644
--- a/src/include/manager.h
+++ b/src/include/manager.h
@@ -179,7 +179,7 @@ private:
     cbSearchResultsLog *m_SearchResultLog;
 };
 
-template <class MgrT> class Mgr
+template <class MgrT> class DLLIMPORT Mgr
 {
     static MgrT *instance;
     static bool isShutdown;
diff --git a/src/include/scrollingdialog.h b/src/include/scrollingdialog.h
index 33725fe..072d578 100644
--- a/src/include/scrollingdialog.h
+++ b/src/include/scrollingdialog.h
@@ -159,7 +159,7 @@ protected:
  * A class that makes its content scroll if necessary
  */
 
-class wxScrollingDialog: public wxDialog
+class DLLIMPORT wxScrollingDialog: public wxDialog
 #if !wxCHECK_VERSION(2,9,0)
     , public wxDialogHelper
 #endif
diff --git a/src/include/xtra_res.h b/src/include/xtra_res.h
index b8848d5..35494e3 100644
--- a/src/include/xtra_res.h
+++ b/src/include/xtra_res.h
@@ -13,7 +13,7 @@
 
 class wxXmlResourceHandler;
 
-class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
+class DLLIMPORT wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
 {
     public:
         wxToolBarAddOnXmlHandler();
@@ -30,7 +30,7 @@ class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
             wxSize size = wxDefaultSize);
 };
 
-class wxScrollingDialogXmlHandler : public wxDialogXmlHandler
+class DLLIMPORT wxScrollingDialogXmlHandler : public wxDialogXmlHandler
 {
     DECLARE_DYNAMIC_CLASS(wxScrollingDialogXmlHandler)
 
diff --git a/src/sdk/scrollingdialog.cpp b/src/sdk/scrollingdialog.cpp
index e847775..cef22e8 100644
--- a/src/sdk/scrollingdialog.cpp
+++ b/src/sdk/scrollingdialog.cpp
@@ -8,8 +8,9 @@
 // Copyright:   (c) Julian Smart
 // Licence:
 /////////////////////////////////////////////////////////////////////////////
+#include "sdk_precomp.h"
+
 
-#include "wx/wx.h"
 #include "wx/module.h"
 #include "wx/display.h"
 #include "wx/bookctrl.h"


But I still see the undefined reference to wxScintilla when building src target
Code
[100.0%] g++.exe -Lbase\tinyxml -LD:\wx3\lib\gcc_dll -Ldevel30 -Lexchndl\win32\lib -o devel30\codeblocks.exe .objs30\src\app.o .objs30\src\appglobals.o .objs30\src\associations.o .objs30\src\backtracedlg.o .objs30\src\breakpointsdlg.o .objs30\src\compilersettingsdlg.o .objs30\src\cpuregistersdlg.o .objs30\src\crashhandler.o .objs30\src\debugger_interface_creator.o .objs30\src\debuggermenu.o .objs30\src\debuggersettingscommonpanel.o .objs30\src\debuggersettingsdlg.o .objs30\src\debuggersettingspanel.o .objs30\src\disassemblydlg.o .objs30\src\dlgabout.o .objs30\src\dlgaboutplugin.o .objs30\src\editkeywordsdlg.o .objs30\src\editorconfigurationdlg.o .objs30\src\environmentsettingsdlg.o .objs30\src\examinememorydlg.o .objs30\src\find_replace.o .objs30\src\infopane.o .objs30\src\main.o .objs30\src\notebookstyles.o .objs30\src\printdlg.o .objs30\src\projectdepsdlg.o .objs30\src\projectmanagerui.o .objs30\src\projectoptionsdlg.o .objs30\src\recentitemslist.o .objs30\src\scriptconsole.o .objs30\src\scriptingsettingsdlg.o .objs30\src\splashscreen.o .objs30\src\startherepage.o .objs30\src\switcherdlg.o .objs30\src\threadsdlg.o .objs30\src\virtualbuildtargetsdlg.o .objs30\src\watchesdlg.o  .objs30\src\resources\resources.res -Wl,--enable-auto-import -Wl,--no-undefined  -lcodeblocks -lexchndl -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw30ud -mwindows
.objs30\src\crashhandler.o: In function `Z27CrashHandlerSaveEditorFilesR8wxString':
F:\cb_sf_git\trunk\src/src/crashhandler.cpp:62: undefined reference to `wxScintilla::GetText() const'
.objs30\src\debugger_interface_creator.o: In function `ZN21DebugInterfaceFactory16ShowValueTooltipERKNSt3tr110shared_ptrI7cbWatchEERK6wxRect':
F:\cb_sf_git\trunk\src/src/debugger_interface_creator.cpp:216: undefined reference to `wxScintilla::CallTipActive()'
.objs30\src\debuggermenu.o: In function `ZN19DebuggerMenuHandler13OnRunToCursorER14wxCommandEvent':
F:\cb_sf_git\trunk\src/src/debuggermenu.cpp:631: undefined reference to `wxScintilla::GetCurrentLine()'
F:\cb_sf_git\trunk\src/src/debuggermenu.cpp:631: undefined reference to `wxScintilla::GetLine(int) const'
F:\cb_sf_git\trunk\src/src/debuggermenu.cpp:643: undefined reference to `wxScintilla::GetCurrentLine()'
.objs30\src\debuggermenu.o: In function `ZN19DebuggerMenuHandler18OnSetNextStatementER14wxCommandEvent':
F:\cb_sf_git\trunk\src/src/debuggermenu.cpp:655: undefined reference to `wxScintilla::GetCurrentLine()'
.objs30\src\disassemblydlg.o: In function `ZN14DisassemblyDlgC2EP8wxWindow':
F:\cb_sf_git\trunk\src/src/disassemblydlg.cpp:55: undefined reference to `wxSCINameStr'
F:\cb_sf_git\trunk\src/src/disassemblydlg.cpp:55: undefined reference to `wxScintilla::wxScintilla(wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&)'
...
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 13, 2015, 04:14:43 pm
OK, I find the reason why I get the error: undefined reference to `wxScintilla::xxxxx

This is because the WXEXPORT is defined to empty!

To find this, I use a method to print the value of WXEXPORT(See here: c - How do I show the value of a #define at compile-time? - Stack Overflow (http://stackoverflow.com/questions/1562074/how-do-i-show-the-value-of-a-define-at-compile-time))

Then, I just add those code to the end of the file "sdk\cbstyledtextctrl.cpp".
Code
/* definition to expand macro then apply to pragma message */
#define VALUE_TO_STRING(x) #x
#define VALUE(x) VALUE_TO_STRING(x)
#define VAR_NAME_VALUE(var) #var "="  VALUE(var)

/* Some example here */
#ifdef WXEXPORT
    #pragma message(VAR_NAME_VALUE(WXEXPORT))
#else
    #pragma message("WXEXPORT not defined")
#endif

Then I build the SDK target, I see such message:
Code
-------------- Build: sdk in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c sdk\cbstyledtextctrl.cpp -o .objs30\sdk\cbstyledtextctrl.o
sdk\cbstyledtextctrl.cpp:551:45: note: #pragma message: WXEXPORT=
     #pragma message(VAR_NAME_VALUE(WXEXPORT))
                                             ^

Look, the WXEXPORT is defined as empty string.

Now, we have code in "sdk\wxscintilla\include\wx\wxscintilla.h"
Code
#ifdef WXMAKINGDLL_SCI
    #define WXDLLIMPEXP_SCI WXEXPORT
#elif defined(WXUSINGDLL_SCI) || defined(WXUSINGDLL)
    #define WXDLLIMPEXP_SCI WXIMPORT
#else // not making nor using DLL
    #define WXDLLIMPEXP_SCI
#endif
...
...
...
class WXDLLIMPEXP_SCI wxScintilla : public wxControl {
public:

#ifdef SWIG
    %pythonAppend wxScintilla   "self._setOORInfo(self)"
    %pythonAppend wxScintilla() ""

    wxScintilla (wxWindow *parent, wxWindowID id=wxID_ANY,
                 const wxPoint& pos = wxDefaultPosition,
                 const wxSize& size = wxDefaultSize, long style = 0,
                 const wxString& name = wxPySCINameStr);
    %RenameCtor(PreScintilla, wxScintilla());

#else
    wxScintilla (wxWindow *parent, wxWindowID id=wxID_ANY,
                 const wxPoint& pos = wxDefaultPosition,
                 const wxSize& size = wxDefaultSize, long style = 0,
                 const wxString& name = wxSCINameStr);
    wxScintilla() { m_swx = NULL; }
    ~wxScintilla();

#endif
...
As we already defined the "WXMAKINGDLL_SCI", but the bad thing is "WXDLLIMPEXP_SCI" now is actually empty. Thus, this class is not exported from the codeblocks.dll.
We need the  "__declspec(dllexport)" decoration here.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 13, 2015, 04:27:44 pm
Let's see where the WXEXPORT comes, it is in D:\wx3\include\wx\dlimpexp.h
Code
#if defined(HAVE_VISIBILITY)
#    define WXEXPORT __attribute__ ((visibility("default")))
#    define WXIMPORT __attribute__ ((visibility("default")))
#elif defined(__WINDOWS__)
    /*
       __declspec works in BC++ 5 and later, Watcom C++ 11.0 and later as well
       as VC++.
     */
#    if defined(__VISUALC__) || defined(__BORLANDC__) || defined(__WATCOMC__)
#        define WXEXPORT __declspec(dllexport)
#        define WXIMPORT __declspec(dllimport)
    /*
        While gcc also supports __declspec(dllexport), it creates unusably huge
        DLL files since gcc 4.5 (while taking horribly long amounts of time),
        see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601. Because of this
        we rely on binutils auto export/import support which seems to work
        quite well for 4.5+.
     */
#    elif defined(__GNUC__) && !wxCHECK_GCC_VERSION(4, 5)
        /*
            __declspec could be used here too but let's use the native
            __attribute__ instead for clarity.
        */
#       define WXEXPORT __attribute__((dllexport))
#       define WXIMPORT __attribute__((dllimport))
#    endif
#elif defined(__WXPM__)
#    if defined (__WATCOMC__)
#        define WXEXPORT __declspec(dllexport)
        /*
           __declspec(dllimport) prepends __imp to imported symbols. We do NOT
           want that!
         */
#        define WXIMPORT
#    elif defined(__EMX__)
#        define WXEXPORT
#        define WXIMPORT
#    elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 )))
#        define WXEXPORT _Export
#        define WXIMPORT _Export
#    endif
#elif defined(__CYGWIN__)
#    define WXEXPORT __declspec(dllexport)
#    define WXIMPORT __declspec(dllimport)
#endif

/* for other platforms/compilers we don't anything */
#ifndef WXEXPORT
#    define WXEXPORT
#    define WXIMPORT
#endif
...

Look at the line
Code
elif defined(__GNUC__) && !wxCHECK_GCC_VERSION(4, 5)
I think we get false value here, so the final active preprocessor is:
Code
/* for other platforms/compilers we don't anything */
#ifndef WXEXPORT
#    define WXEXPORT
#    define WXIMPORT
#endif

So, one solution is re-define WXEXPORT in the sdk\cbstyledtextctrl.cpp.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 13, 2015, 05:08:25 pm
OK, linking to the wxScintilla issue is solved by the following test patch:
Code
 src/CodeBlocks_wx30.cbp                 |  1 -
 src/include/cbexception.h               |  2 +-
 src/include/cbstyledtextctrl.h          |  2 +-
 src/include/editorcolourset.h           |  2 +-
 src/include/filemanager.h               |  4 ++--
 src/include/manager.h                   |  2 +-
 src/include/scrollingdialog.h           |  2 +-
 src/include/xtra_res.h                  |  4 ++--
 src/sdk/cbstyledtextctrl.cpp            | 25 +++++++++++++++++++++++++
 src/sdk/scrollingdialog.cpp             |  3 ++-
 src/sdk/wxscintilla/src/wxscintilla.cpp | 28 ++++++++++++++++++++++++++++
 11 files changed, 64 insertions(+), 11 deletions(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index ac09ab1..5a304dd 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -136,7 +136,6 @@
  </Compiler>
  <Linker>
  <Add option="-Wl,--enable-auto-image-base" />
- <Add option="-Wl,--export-all-symbols" />
  <Add option="-Wl,--add-stdcall-alias" />
  <Add option="-Wl,--enable-auto-import" />
  <Add option="-Wl,--no-undefined" />
diff --git a/src/include/cbexception.h b/src/include/cbexception.h
index 2044dd9..bfa91bc 100644
--- a/src/include/cbexception.h
+++ b/src/include/cbexception.h
@@ -20,7 +20,7 @@ cbThrow() and cbAssert().
 */
 
 /** @brief The base Code::Blocks exception object. */
-class cbException
+class DLLIMPORT cbException
 {
     public:
         cbException(const wxString& msg, const wxString& file, int line);
diff --git a/src/include/cbstyledtextctrl.h b/src/include/cbstyledtextctrl.h
index 55835a3..77c3d78 100644
--- a/src/include/cbstyledtextctrl.h
+++ b/src/include/cbstyledtextctrl.h
@@ -17,7 +17,7 @@ class wxFocusEvent;
 class wxMouseEvent;
 class wxPoint;
 
-class cbStyledTextCtrl : public wxScintilla
+class DLLIMPORT cbStyledTextCtrl : public wxScintilla
 {
     public:
         cbStyledTextCtrl(wxWindow* pParent, int id, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0);
diff --git a/src/include/editorcolourset.h b/src/include/editorcolourset.h
index a6573bd..e79ddac 100644
--- a/src/include/editorcolourset.h
+++ b/src/include/editorcolourset.h
@@ -73,7 +73,7 @@ struct OptionSet
 };
 WX_DECLARE_STRING_HASH_MAP(OptionSet, OptionSetsMap);
 
-class EditorColourSet
+class DLLIMPORT EditorColourSet
 {
     public:
         EditorColourSet(const wxString& setName = COLORSET_DEFAULT);
diff --git a/src/include/filemanager.h b/src/include/filemanager.h
index 343c087..6d80f04 100644
--- a/src/include/filemanager.h
+++ b/src/include/filemanager.h
@@ -28,7 +28,7 @@ namespace TinyXML{ bool SaveDocument(const wxString&, TiXmlDocument*); }
 
 
 // ***** class: LoaderBase *****
-class LoaderBase : public AbstractJob
+class DLLIMPORT LoaderBase : public AbstractJob
 {
     wxSemaphore sem;
     bool wait;
@@ -109,7 +109,7 @@ public:
 };
 
 // ***** class: FileManager *****
-class FileManager : public Mgr<FileManager>
+class DLLIMPORT FileManager : public Mgr<FileManager>
 {
     BackgroundThread fileLoaderThread;
     BackgroundThread uncLoaderThread;
diff --git a/src/include/manager.h b/src/include/manager.h
index 7dfe827..cd0cb30 100644
--- a/src/include/manager.h
+++ b/src/include/manager.h
@@ -179,7 +179,7 @@ private:
     cbSearchResultsLog *m_SearchResultLog;
 };
 
-template <class MgrT> class Mgr
+template <class MgrT> class DLLIMPORT Mgr
 {
     static MgrT *instance;
     static bool isShutdown;
diff --git a/src/include/scrollingdialog.h b/src/include/scrollingdialog.h
index 33725fe..072d578 100644
--- a/src/include/scrollingdialog.h
+++ b/src/include/scrollingdialog.h
@@ -159,7 +159,7 @@ protected:
  * A class that makes its content scroll if necessary
  */
 
-class wxScrollingDialog: public wxDialog
+class DLLIMPORT wxScrollingDialog: public wxDialog
 #if !wxCHECK_VERSION(2,9,0)
     , public wxDialogHelper
 #endif
diff --git a/src/include/xtra_res.h b/src/include/xtra_res.h
index b8848d5..35494e3 100644
--- a/src/include/xtra_res.h
+++ b/src/include/xtra_res.h
@@ -13,7 +13,7 @@
 
 class wxXmlResourceHandler;
 
-class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
+class DLLIMPORT wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
 {
     public:
         wxToolBarAddOnXmlHandler();
@@ -30,7 +30,7 @@ class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
             wxSize size = wxDefaultSize);
 };
 
-class wxScrollingDialogXmlHandler : public wxDialogXmlHandler
+class DLLIMPORT wxScrollingDialogXmlHandler : public wxDialogXmlHandler
 {
     DECLARE_DYNAMIC_CLASS(wxScrollingDialogXmlHandler)
 
diff --git a/src/sdk/cbstyledtextctrl.cpp b/src/sdk/cbstyledtextctrl.cpp
index 4e3d6c6..dc8d06b 100644
--- a/src/sdk/cbstyledtextctrl.cpp
+++ b/src/sdk/cbstyledtextctrl.cpp
@@ -8,6 +8,16 @@
  */
 
 #include "sdk_precomp.h"
+
+// this workaround an issue that WXEXPORT is defined as empty, so that wxScintilla class is not
+// exported from the codeblocks.dll
+#ifdef __WINDOWS__
+    #ifdef WXEXPORT
+        #undef WXEXPORT
+        #define WXEXPORT __declspec(dllexport)
+    #endif // WXEXPORT
+#endif // __WINDOWS__
+
 #include "cbstyledtextctrl.h"
 #ifndef CB_PRECOMP
     #include <wx/gdicmn.h> // for wxPoint
@@ -539,3 +549,18 @@ void cbStyledTextCtrl::MakeNearbyLinesVisible(int line)
     else if (dist >= LinesOnScreen() - 2)
         LineScroll(0, 3 + dist - LinesOnScreen());
 }
+
+
+/* definition to expand macro then apply to pragma message */
+#define VALUE_TO_STRING(x) #x
+#define VALUE(x) VALUE_TO_STRING(x)
+#define VAR_NAME_VALUE(var) #var "="  VALUE(var)
+
+/* Some example here */
+#ifdef WXEXPORT
+    #pragma message(VAR_NAME_VALUE(WXEXPORT))
+#else
+    #pragma message("WXEXPORT not defined")
+#endif
+
+
diff --git a/src/sdk/scrollingdialog.cpp b/src/sdk/scrollingdialog.cpp
index e847775..cef22e8 100644
--- a/src/sdk/scrollingdialog.cpp
+++ b/src/sdk/scrollingdialog.cpp
@@ -8,8 +8,9 @@
 // Copyright:   (c) Julian Smart
 // Licence:
 /////////////////////////////////////////////////////////////////////////////
+#include "sdk_precomp.h"
+
 
-#include "wx/wx.h"
 #include "wx/module.h"
 #include "wx/display.h"
 #include "wx/bookctrl.h"
diff --git a/src/sdk/wxscintilla/src/wxscintilla.cpp b/src/sdk/wxscintilla/src/wxscintilla.cpp
index ca79dd2..8f033c6 100644
--- a/src/sdk/wxscintilla/src/wxscintilla.cpp
+++ b/src/sdk/wxscintilla/src/wxscintilla.cpp
@@ -45,8 +45,36 @@
 #endif
 
 #include "ScintillaWX.h"
+
+
+// this workaround an issue that WXEXPORT is defined as empty, so that wxScintilla class is not
+// exported from the codeblocks.dll
+#ifdef __WINDOWS__
+    #ifdef WXEXPORT
+        #undef WXEXPORT
+        #define WXEXPORT __declspec(dllexport)
+    #else
+        #define WXEXPORT __declspec(dllexport)
+    #endif // WXEXPORT
+
+#endif // __WINDOWS__
+
+
+
 #include "wx/wxscintilla.h"
 
+/* definition to expand macro then apply to pragma message */
+#define VALUE_TO_STRING(x) #x
+#define VALUE(x) VALUE_TO_STRING(x)
+#define VAR_NAME_VALUE(var) #var "="  VALUE(var)
+
+/* Some example here */
+#ifdef WXEXPORT
+    #pragma message(VAR_NAME_VALUE(WXEXPORT))
+#else
+    #pragma message("WXEXPORT not defined")
+#endif
+
 #ifdef SCI_NAMESPACE
 using namespace Scintilla;
 #endif

It looks like we need to export the functions which are from the static library (libwxscintilla_cb.a), some discussion: Why can't I __declspec(dllexport) a function from a static library? - The Old New Thing - Site Home - MSDN Blogs (http://blogs.msdn.com/b/oldnewthing/archive/2014/03/21/10509670.aspx), my solution is just add __declspec(dllexport) when building the static library.

But I still see other undefined errors.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 13, 2015, 05:15:08 pm
The bad thing is, to solve this kind of error, I also need to add export decoration to squirrel library... :(
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 13, 2015, 08:31:30 pm
The bad thing is, to solve this kind of error, I also need to add export decoration to squirrel library... :(
What is the error related to squirrel?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 14, 2015, 12:58:24 am
The bad thing is, to solve this kind of error, I also need to add export decoration to squirrel library... :(
What is the error related to squirrel?
When build the src target, I get such error:
Code
[100.0%] g++.exe -Lbase\tinyxml -LD:\wx3\lib\gcc_dll -Ldevel30 -Lexchndl\win32\lib -o devel30\codeblocks.exe .objs30\src\app.o .objs30\src\appglobals.o .objs30\src\associations.o .objs30\src\backtracedlg.o .objs30\src\breakpointsdlg.o .objs30\src\compilersettingsdlg.o .objs30\src\cpuregistersdlg.o .objs30\src\crashhandler.o .objs30\src\debugger_interface_creator.o .objs30\src\debuggermenu.o .objs30\src\debuggersettingscommonpanel.o .objs30\src\debuggersettingsdlg.o .objs30\src\debuggersettingspanel.o .objs30\src\disassemblydlg.o .objs30\src\dlgabout.o .objs30\src\dlgaboutplugin.o .objs30\src\editkeywordsdlg.o .objs30\src\editorconfigurationdlg.o .objs30\src\environmentsettingsdlg.o .objs30\src\examinememorydlg.o .objs30\src\find_replace.o .objs30\src\infopane.o .objs30\src\main.o .objs30\src\notebookstyles.o .objs30\src\printdlg.o .objs30\src\projectdepsdlg.o .objs30\src\projectmanagerui.o .objs30\src\projectoptionsdlg.o .objs30\src\recentitemslist.o .objs30\src\scriptconsole.o .objs30\src\scriptingsettingsdlg.o .objs30\src\splashscreen.o .objs30\src\startherepage.o .objs30\src\switcherdlg.o .objs30\src\threadsdlg.o .objs30\src\virtualbuildtargetsdlg.o .objs30\src\watchesdlg.o  .objs30\src\resources\resources.res -Wl,--enable-auto-import -Wl,--no-undefined  -lcodeblocks -lexchndl -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw30ud -mwindows
.objs30\src\main.o: In function `ZN12StackHandlerC1EP4SQVM':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelObject.h:105: undefined reference to `sq_gettop'
.objs30\src\main.o: In function `ZN12StackHandler15GetObjectHandleEi':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelObject.h:125: undefined reference to `sq_resetobject'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelObject.h:126: undefined reference to `sq_getstackobj'
.objs30\src\main.o: In function `ZN12StackHandler13GetInstanceUpEiPv':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelObject.h:149: undefined reference to `sq_getinstanceup'
.objs30\src\main.o: In function `ZN12StackHandler11GetUserDataEiPv':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelObject.h:158: undefined reference to `sq_getuserdata'
.objs30\src\main.o: In function `ZN10SquirrelVM8GetVMPtrEv':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/SquirrelVM.h:58: undefined reference to `SquirrelVM::_VM'
.objs30\src\main.o: In function `ZN6SqPlus6VarRefC1EPvNS_13ScriptVarTypeES1_PFvS1_S1_EiNS_13VarAccessTypeEPKc':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:307: undefined reference to `SquirrelVM::GetRootTable()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:307: undefined reference to `SquirrelObject::GetValue(char const*) const'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:308: undefined reference to `SquirrelObject::IsNull() const'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:309: undefined reference to `SquirrelVM::CreateTable()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:309: undefined reference to `SquirrelObject::operator=(SquirrelObject const&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:309: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:310: undefined reference to `SquirrelVM::GetRootTable()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:310: undefined reference to `SquirrelObject::SquirrelObject(SquirrelObject const&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:311: undefined reference to `SquirrelObject::SetValue(char const*, SquirrelObject const&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:310: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:313: undefined reference to `SquirrelObject::SetValue(int, char const*)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:307: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:309: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:310: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:307: undefined reference to `SquirrelObject::~SquirrelObject()'
.objs30\src\main.o: In function `ZN6SqPlus25createTableSetGetHandlersER14SquirrelObject':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:349: undefined reference to `SquirrelObject::GetDelegate()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:350: undefined reference to `SquirrelObject::Exists(char const*) const'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:351: undefined reference to `SquirrelVM::CreateTable()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:351: undefined reference to `SquirrelObject::operator=(SquirrelObject const&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:351: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:352: undefined reference to `SqPlus::setVarFunc(SQVM*)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:352: undefined reference to `SquirrelVM::CreateFunction(SquirrelObject&, int (*)(SQVM*), char const*, char const*)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:352: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:353: undefined reference to `SqPlus::getVarFunc(SQVM*)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:353: undefined reference to `SquirrelVM::CreateFunction(SquirrelObject&, int (*)(SQVM*), char const*, char const*)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:353: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:354: undefined reference to `SquirrelObject::SetDelegate(SquirrelObject&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:349: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:351: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:349: undefined reference to `SquirrelObject::~SquirrelObject()'
.objs30\src\main.o: In function `ZN6SqPlus12createVarRefER14SquirrelObjectPKc':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:361: undefined reference to `SquirrelObject::GetUserData(char const*, void**, void**)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:362: undefined reference to `SquirrelObject::NewUserData(char const*, int, void**)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:363: undefined reference to `SquirrelObject::GetUserData(char const*, void**, void**)'
.objs30\src\main.o: In function `ZN6SqPlus4PushEP4SQVMb':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1873: undefined reference to `sq_pushbool'
.objs30\src\main.o: In function `ZN6SqPlus5MatchENS_11TypeWrapperIbEEP4SQVMi':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1881: undefined reference to `sq_gettype'
.objs30\src\main.o: In function `ZN6SqPlus3GetENS_11TypeWrapperIbEEP4SQVMi':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1900: undefined reference to `sq_getbool'
.objs30\src\main.o: In function `ZN6SqPlus10SQClassDefI9MainFrameED1Ev':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1715: undefined reference to `SquirrelObject::~SquirrelObject()'
.objs30\src\main.o: In function `ZN6SqPlus11GetInstanceI8wxStringLb0EEEPT_P4SQVMi':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:532: undefined reference to `sq_getinstanceup'
.objs30\src\main.o: In function `ZN6SqPlus11GetInstanceI8wxStringLb1EEEPT_P4SQVMi':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:532: undefined reference to `sq_getinstanceup'
.objs30\src\main.o: In function `ZN6SqPlus10SQClassDefI9MainFrameEC1EPKcS4_':
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1727: undefined reference to `SquirrelObject::SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1729: undefined reference to `SquirrelObject::operator=(SquirrelObject const&)'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1729: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1729: undefined reference to `SquirrelObject::~SquirrelObject()'
F:\cb_sf_git\trunk\src/include/scripting/sqplus/sqplus.h:1727: undefined reference to `SquirrelObject::~SquirrelObject()'
Process terminated with status 1 (1 minute(s), 0 second(s))
50 error(s), 0 warning(s) (1 minute(s), 0 second(s))

This means, those symbols are not exported from codeblocks.dll. Actually, they are inside the squirrel related static library. So you see the symbols are in the static library, but they should be exported through the dll(dynamic library).
In this case, the symbol should be marked as dllexport.
EDIT: after the change, the static library should be rebuild again.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 14, 2015, 08:40:23 am
This means, those symbols are not exported from codeblocks.dll. Actually, they are inside the squirrel related static library. So you see the symbols are in the static library, but they should be exported through the dll(dynamic library).
In this case, the symbol should be marked as dllexport.
EDIT: after the change, the static library should be rebuild again.
Why do you think this is a good idea? I think it is not, because everybody linking to libsquirrel.a will export the symbols, which is bad.
Have you tried linking codeblocks.exe with libsquirrel.a and all the others?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on October 14, 2015, 05:54:39 pm
This means, those symbols are not exported from codeblocks.dll. Actually, they are inside the squirrel related static library. So you see the symbols are in the static library, but they should be exported through the dll(dynamic library).
In this case, the symbol should be marked as dllexport.
EDIT: after the change, the static library should be rebuild again.
Why do you think this is a good idea? I think it is not, because everybody linking to libsquirrel.a will export the symbols, which is bad.
Have you tried linking codeblocks.exe with libsquirrel.a and all the others?

IMO, The only thing linking to the libsquirrel.a should be the Code::Blocks DLL, do you disagree?

Tim S.

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 14, 2015, 09:11:13 pm
I'm not sure about this, because other parts of the code use Squirrel APIs directly.
Thus either everything that uses squirrel has to link to squirrel's lib or codeblocks.dll has to export all used APIs.

The only benefit if we use the latter option is that any globals and static will be defined just once.
I guess, I'll have to resurrect my patches that try to introduce hidden visibility on linux.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 15, 2015, 06:48:52 am
I'm not sure about this, because other parts of the code use Squirrel APIs directly.
I see that all plugins in Windows Codeblocks*.cbp only link to the codeblocks.dll, and not extra static library is need here.
The way we build the static libraries (such as libsqplus.a inside \src\sdk\scripting\lib) with export all symbol option enabled, so that the codeblocks.dll are export all the symbols of those static libraries.

If the plugin is explicitly link to a static library, such as libsqplus.a, then the piece of code is in both codeblocks.dll and the plugin.dll.

I'm OK this this design.

@Tim: if you want to use __declspec(dllimport), then we will finally need two pchs, because on pch are for SDK(with many __declspec(dllexport) decoration for symbols) and another pch is for src and plugin targets (with __declspec(dllimport) decoration for symbols).
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 16, 2015, 02:19:20 am
It looks like the wxWidgets dll we build by the command like "mingw32-make ....", which does not have dllexport decortation enabled. See "D:\wx3\include\wx\dlimpexp.h", this means the mingw's linker option: "-export-all-symbols" is enabled by default.

I have manfully add DLLIMPORT to many sdk's headers, and currently, sdk and src, some plugins are build fine. (in this case, need to use the "-export-all-symbols" when building sdk)

But I see one error when building compiler plugin:
Code
-------------- Build: Compiler in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LD:\wx3\lib\gcc_dll -Ldevel30 -Lplugins\compilergcc\depslib .objs30\plugins\compilergcc\advancedcompileroptionsdlg.o .objs30\plugins\compilergcc\compiler_defs.o .objs30\plugins\compilergcc\compilerCYGWIN.o .objs30\plugins\compilergcc\compilererrors.o .objs30\plugins\compilergcc\compilerflagdlg.o .objs30\plugins\compilergcc\compilerG95.o .objs30\plugins\compilergcc\compilergcc.o .objs30\plugins\compilergcc\compilerGDC.o .objs30\plugins\compilergcc\compilerGNUARM.o .objs30\plugins\compilergcc\compilerGNUFortran.o .objs30\plugins\compilergcc\compilerIAR.o .objs30\plugins\compilergcc\compilerICC.o .objs30\plugins\compilergcc\compilerKeilC51.o .objs30\plugins\compilergcc\compilerLCC.o .objs30\plugins\compilergcc\compilermessages.o .objs30\plugins\compilergcc\compilerMINGW.o .objs30\plugins\compilergcc\compilerMINGWgenerator.o .objs30\plugins\compilergcc\compilerMSVC.o .objs30\plugins\compilergcc\compilerMSVC10.o .objs30\plugins\compilergcc\compilerMSVC8.o .objs30\plugins\compilergcc\compileroptionsdlg.o .objs30\plugins\compilergcc\compilerOW.o .objs30\plugins\compilergcc\compilerOWgenerator.o .objs30\plugins\compilergcc\compilerXML.o .objs30\plugins\compilergcc\directcommands.o  -o devel30\share\CodeBlocks\plugins\compiler.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined -mthreads  -lcodeblocks -lwxmsw30ud -ldepslib
.objs30\plugins\compilergcc\advancedcompileroptionsdlg.o: In function `ZN26AdvancedCompilerOptionsDlgC2EP8wxWindowRK8wxString':
F:\cb_sf_git\trunk\src/plugins/compilergcc/advancedcompileroptionsdlg.cpp:72: undefined reference to `RegExArray::~RegExArray()'
.objs30\plugins\compilergcc\advancedcompileroptionsdlg.o: In function `ZN26AdvancedCompilerOptionsDlgD2Ev':
F:\cb_sf_git\trunk\src/plugins/compilergcc/advancedcompileroptionsdlg.cpp:82: undefined reference to `RegExArray::~RegExArray()'
F:\cb_sf_git\trunk\src/plugins/compilergcc/advancedcompileroptionsdlg.cpp:82: undefined reference to `RegExArray::~RegExArray()'

While, I found that RegExArray is defined in sdk's header
Code
WX_DECLARE_OBJARRAY(RegExStruct, RegExArray);
Refer to the wx's document: wxWidgets: interface/wx/dynarray.h File Reference (http://docs.wxwidgets.org/trunk/dynarray_8h.html#a6c4cbd97b2b8c79aef39d55f35686f96), I change to the export version of this macro
Code
WX_DECLARE_EXPORTED_OBJARRAY(RegExStruct, RegExArray);

But the linker error still happens. I looked at this macro:
Code
#define WX_DECLARE_EXPORTED_OBJARRAY(T, name)               \
    WX_DECLARE_USER_EXPORTED_OBJARRAY(T, name, WXDLLIMPEXP_CORE)
And something in "D:\wx3\include\wx\dlimpexp.h"
Code
#ifdef WXMAKINGDLL_CORE
#    define WXDLLIMPEXP_CORE WXEXPORT
#    define WXDLLIMPEXP_DATA_CORE(type) WXEXPORT type
#    if defined(HAVE_VISIBILITY)
#        define WXDLLIMPEXP_INLINE_CORE WXEXPORT
#    else
#        define WXDLLIMPEXP_INLINE_CORE
#    endif
#elif defined(WXUSINGDLL)
#    define WXDLLIMPEXP_CORE WXIMPORT
#    define WXDLLIMPEXP_DATA_CORE(type) WXIMPORT type
#    if defined(HAVE_VISIBILITY)
#        define WXDLLIMPEXP_INLINE_CORE WXIMPORT
#    else
#        define WXDLLIMPEXP_INLINE_CORE
#    endif
#else /* not making nor using DLL */
#    define WXDLLIMPEXP_CORE
#    define WXDLLIMPEXP_DATA_CORE(type) type
#    define WXDLLIMPEXP_INLINE_CORE
#endif

This means WXDLLIMPEXP_CORE is expanded to an empty string... Thus, RegExArray can't be exported easily.  :(
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 16, 2015, 02:41:36 am
Well, it looks like wxWidgets is explicitly use the auto import/export method, see the comments in dllimpexp.h
Code
#if defined(HAVE_VISIBILITY)
#    define WXEXPORT __attribute__ ((visibility("default")))
#    define WXIMPORT __attribute__ ((visibility("default")))
#elif defined(__WINDOWS__)
    /*
       __declspec works in BC++ 5 and later, Watcom C++ 11.0 and later as well
       as VC++.
     */
#    if defined(__VISUALC__) || defined(__BORLANDC__) || defined(__WATCOMC__)
#        define WXEXPORT __declspec(dllexport)
#        define WXIMPORT __declspec(dllimport)
    /*
        While gcc also supports __declspec(dllexport), it creates unusably huge
        DLL files since gcc 4.5 (while taking horribly long amounts of time),
        see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601. Because of this
        we rely on binutils auto export/import support which seems to work
        quite well for 4.5+.
     */
#    elif defined(__GNUC__) && !wxCHECK_GCC_VERSION(4, 5)
        /*
            __declspec could be used here too but let's use the native
            __attribute__ instead for clarity.
        */
#       define WXEXPORT __attribute__((dllexport))
#       define WXIMPORT __attribute__((dllimport))
#    endif
#elif defined(__WXPM__)
#    if defined (__WATCOMC__)
#        define WXEXPORT __declspec(dllexport)
        /*
           __declspec(dllimport) prepends __imp to imported symbols. We do NOT
           want that!
         */
#        define WXIMPORT
#    elif defined(__EMX__)
#        define WXEXPORT
#        define WXIMPORT
#    elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 )))
#        define WXEXPORT _Export
#        define WXIMPORT _Export
#    endif
#elif defined(__CYGWIN__)
#    define WXEXPORT __declspec(dllexport)
#    define WXIMPORT __declspec(dllimport)
#endif

/* for other platforms/compilers we don't anything */
#ifndef WXEXPORT
#    define WXEXPORT
#    define WXIMPORT
#endif

Especially
Code
    /*
        While gcc also supports __declspec(dllexport), it creates unusably huge
        DLL files since gcc 4.5 (while taking horribly long amounts of time),
        see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601. Because of this
        we rely on binutils auto export/import support which seems to work
        quite well for 4.5+.
     */
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 16, 2015, 07:09:06 am
I asked a question on the wx user maillist build wxWidgets dll without __declspec(dllexport) for MinGW target - Google Groups (https://groups.google.com/forum/?fromgroups#!topic/wx-users/BLeNygSYyx0), it looks like someone has already done that:

Re: Compiling wxWidgets (https://forums.wxwidgets.org/viewtopic.php?t=38521#p156966)
Or
MINGW-packages/wxWidgets-3.0.0-gcc-codelight.patch at master · Alexpux/MINGW-packages (https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-wxwidgets/wxWidgets-3.0.0-gcc-codelight.patch)

This does not export the unnecessary symbol, and reduce the wx's dll size, also it can app's improve the startup time.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 16, 2015, 05:25:01 pm
Good news: I have successfully build all targets inside codeblocks-wx30.cbp, with sdk only export symbols through the dllexport decoration, and I checked the codeblocks.dll, and it export about 3000 symbols, and the old way(all the symbols are exported), I see it export 9000 symbols, that reduced 2/3, great!

I will post the full patch tomorrow. :) It's late today.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 17, 2015, 05:02:26 pm
OK, now the patches(git style patch serials) are in Code::Blocks / Tickets / #239 reduce exported symbols from codeblocks.dll (https://sourceforge.net/p/codeblocks/tickets/239/)

I mainly do the following things in those patches:
1, only one pch file is used to build C::B.
2, some symbols in static libraries(such as some symbols in sqplus) are marked as "dllexport", and he symbols are exported in codeblocks.dll. So that all the src and plugin target only need to link against codeblocks.dll. No need to link to those static library(such as sqplus.a).
(Note that also build wxWidgets 3.0.2 library with the change of only export the dllexport maked symbol, which reduce the dll size, see build wxWidgets dll without __declspec(dllexport) for MinGW target - Google Groups (https://groups.google.com/forum/?fromgroups#!topic/wx-users/BLeNygSYyx0) for more details.


BTW: I see one issue is that some static library is stored in the folder "src\sdk\scripting\lib", this means they are shared with both codeblocks.cbp and codeblocks-wx30.cbp, this may cause some conflicts.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: MortenMacFly on October 17, 2015, 07:57:05 pm
BTW: I see one issue is that some static library is stored in the folder "src\sdk\scripting\lib", this means they are shared with both codeblocks.cbp and codeblocks-wx30.cbp, this may cause some conflicts.
This is not an issue, as the scripting lib is independent of wxWidgets. Thus, if you compile it with the same compiler it will result in the same binary. Its different for the 64 bit build though... but just not because wx30-64 bit but because the lib will be 64 bit then.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on October 26, 2015, 03:50:02 am
look at this,is there will be a wx3.02 and 64bit release?i don't know much,i complie wx3.02 use nuwen's mingw64 distro from nuwen.net or http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/5.x/ this mingw64 build ,it work just fine,complie wx3.02 must use -std=gnu++11
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 26, 2015, 05:47:54 am
look at this,is there will be a wx3.02 and 64bit release?i don't know much,i complie wx3.02 use nuwen's mingw64 distro from nuwen.net or http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/5.x/ this mingw64 build ,it work just fine,complie wx3.02 must use -std=gnu++11
Hi, mageia, I don't think a wx 3.0.2 release soon, we are on the way of migration from wx2.8.x to wx 3.x, but there are issues need to be fixed here and there in our C::B source code.

I know use the "-std=gnu++11" can fix the build issue, but no such option is also OK to build the wx3.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 26, 2015, 06:02:54 am
FYI: yesterday, explicitly dll export is enabled in the wx trunk for mingw target, see this post:

https://groups.google.com/d/msg/wx-users/BLeNygSYyx0/-57vTa3CAwAJ

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on October 26, 2015, 01:02:29 pm
i know your guys all big,i just want to know there will push out a edition with wx3 or not,now i know,i google for -std=gnu++11 couple days ,oops~~~
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 29, 2015, 02:50:11 pm
OK, now the patches(git style patch serials) are in Code::Blocks / Tickets / #239 reduce exported symbols from codeblocks.dll (https://sourceforge.net/p/codeblocks/tickets/239/)

I mainly do the following things in those patches:
1, only one pch file is used to build C::B.
2, some symbols in static libraries(such as some symbols in sqplus) are marked as "dllexport", and he symbols are exported in codeblocks.dll. So that all the src and plugin target only need to link against codeblocks.dll. No need to link to those static library(such as sqplus.a).
(Note that also build wxWidgets 3.0.2 library with the change of only export the dllexport maked symbol, which reduce the dll size, see build wxWidgets dll without __declspec(dllexport) for MinGW target - Google Groups (https://groups.google.com/forum/?fromgroups#!topic/wx-users/BLeNygSYyx0) for more details.


@Morten and other devs, I'm going to commit parts of the above serials, which only add the add DLLIMPORT or EVTIMPORT decorations to some symbols in our code base, this currently doesn't affect the build system, since we still export all symbols from the SDK dll. But this can make it much easier if we later only export the necessary symbols from the SDK dll.

Do you have any objections?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 29, 2015, 08:15:44 pm
Do you have any objections?
Can you wait couple of days, so I can find some time to test them?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: MortenMacFly on October 29, 2015, 09:24:20 pm
Can you wait couple of days, so I can find some time to test them?
I am not even able to test them due to the format, unfortunately...
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 30, 2015, 08:12:24 am
Morten: There you go https://github.com/obfuscated/codeblocks_sf/tree/ollydbg/visibility_hidden

I've tried to do similar work on enabling -fvisibility=hidden on linux. The patches can be found in this branch https://github.com/obfuscated/codeblocks_sf/tree/visibility_hidden Some of them are similar to yours.

ollydbg: These patches fail to compile on linux (I've fixed it in the branch). Also they do stuff that they should not.
Like:
1. The patch that changes the link to wx3-debug should not be pushed
2. Exporting functions/classes from tinyxml is wrong. Same for the other static libraries. Project needing the libs should link directly. Squirrel stuff was tricky, because of globals.
3. Why do you need the workaround commits? Just include the settings.h header?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on October 30, 2015, 01:11:15 pm
ollydbg: These patches fail to compile on linux (I've fixed it in the branch). Also they do stuff that they should not.
Like:
1. The patch that changes the link to wx3-debug should not be pushed
Sure, I won't plan to push this commit to our svn repo. On my test, C::B crashes if it link to wx3 release library(build with g++ -O2) under Windows XP, so I have to use the debug version of wx3(build with g++ -O0).

Quote
2. Exporting functions/classes from tinyxml is wrong. Same for the other static libraries. Project needing the libs should link directly. Squirrel stuff was tricky, because of globals.
Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.

Quote
3. Why do you need the workaround commits? Just include the settings.h header?
The macro "WXEXPORT" is defined as empty in wxWidgets header, which make all the symbols were exported from wxWidgets shared dll. (This issue is solved by a recent commit in wx's trunk https://groups.google.com/d/msg/wx-users/BLeNygSYyx0/-57vTa3CAwAJ (https://groups.google.com/d/msg/wx-users/BLeNygSYyx0/-57vTa3CAwAJ) I have mentioned before.

The reason why I don't use settings.h is that it does not works OK, see below:
Code
#ifndef SETTINGS_H
#define SETTINGS_H

/*
Exclude VC++, because it has silly constraints on importing/exporting classes
from DLLs. Instead, we build "sdk" as a static library
*/
#if defined(__WXMSW__)
#ifndef DLLIMPORT
#if defined(EXPORT_LIB)
#define DLLIMPORT __declspec (dllexport)
#else
#define DLLIMPORT __declspec (dllimport)
#endif // EXPORT_LIB
#endif // DLLIMPORT
#ifndef EVTIMPORT
#if defined(EXPORT_EVENTS)
#define EVTIMPORT __declspec (dllexport)
#else
#define EVTIMPORT __declspec (dllimport)
#endif // EXPORT_EVENTS
#endif // EVTIMPORT
#else
#define DLLIMPORT
#define EVTIMPORT
#endif

#endif // SETTINGS_H

When building the static libraries mentioned before, __WXMSW__ is not defined(no wx header is included to build the static libraries). This still make the DLLIMPORT as an empty string. Unless you change the __WXMSW__ to some other windows specific macros, like _WIN32 or others.

EDIT: look at the code: "#ifndef DLLIMPORT", here DLLIMPORT is defined as empty inside the wxwdigets' header files, actually we need to overwrite this definition.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on October 31, 2015, 01:03:07 am
Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.
Yes, I know and I say this is the wrong way to do it.
All these libs have not been designed to be shared libraries.
If they are we should just build them as such and don't bother with all this trickery.

Also on linux using the default visibility can cause lots of problems and strange crashes.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 06, 2015, 02:00:10 pm
Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.
Yes, I know and I say this is the wrong way to do it.
All these libs have not been designed to be shared libraries.
If they are we should just build them as such and don't bother with all this trickery.

Also on linux using the default visibility can cause lots of problems and strange crashes.
As you suggested, we need to build them as static libraries, and we need to link them as static libraries. A lot of targets need those static libraries, for example, if some plugin need to access the configure file, then we need to link to the static version of the tinyxml library.
Am I right?
If we see this is the correct direction, I may take some time to test it.

EDIT:
what I want to commit are such commits which only add the "DLLIMPORT" macros to the symbols, such as:
- add DLLIMPORT decoration. · obfuscated/codeblocks_sf@c3453df (https://github.com/obfuscated/codeblocks_sf/commit/c3453df84ff5f0ebde832f5da507dd66f2e352b6), this won't change any build target. What's your opinion?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on November 06, 2015, 08:41:51 pm
Yes, adding DLLIMPORT to classes in the sdk or in the include folders is safe and I have no objections, so go on and commit them.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 07, 2015, 10:59:24 am
Yes, adding DLLIMPORT to classes in the sdk or in the include folders is safe and I have no objections, so go on and commit them.
Done in trunk. :)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on November 07, 2015, 12:24:00 pm
Why do you need to export the InfoPane class?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 07, 2015, 02:26:11 pm
Why do you need to export the InfoPane class?
Oh, I see this is a mistake, no need to export the InfoPane class from the file /src/src/infopane.h. I don't see build errors when I remove DLLIMPORT in this file(test with my other patches). So, I will commit the fix soon. Thanks for point this out.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 07, 2015, 03:24:19 pm

Also, I see some warnings from C::B source:

Code
-------------- Build: sdk in Code::Blocks wx3.0.x (compiler: GNU GCC Compiler)---------------

[  0.8%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -Wno-deprecated-declarations -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs30\include -I.objs30\include -I. -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c include\sdk_precomp.h -o .objs30\include\sdk_precomp.h.gch
In file included from include\cbauibook.h:13:0,
                 from include\sdk_common.h:133,
                 from include\sdk_precomp.h:13:
D:\wx3\include/wx/aui/auibook.h:349:18: warning: 'virtual bool wxAuiNotebook::AddPage(wxWindow*, const wxString&, bool, int)' was hidden [-Woverloaded-virtual]
     virtual bool AddPage(wxWindow *page, const wxString &text, bool select,
                  ^
In file included from include\sdk_common.h:133:0,
                 from include\sdk_precomp.h:13:
include\cbauibook.h:141:14: warning:   by 'bool cbAuiNotebook::AddPage(wxWindow*, const wxString&, bool, const wxBitmap&)' [-Woverloaded-virtual]
         bool AddPage(wxWindow* page,
              ^
In file included from include\cbauibook.h:13:0,
                 from include\sdk_common.h:133,
                 from include\sdk_precomp.h:13:
D:\wx3\include/wx/aui/auibook.h:352:18: warning: 'virtual bool wxAuiNotebook::InsertPage(size_t, wxWindow*, const wxString&, bool, int)' was hidden [-Woverloaded-virtual]
     virtual bool InsertPage(size_t index, wxWindow *page, const wxString &text,
                  ^
In file included from include\sdk_common.h:133:0,
                 from include\sdk_precomp.h:13:
include\cbauibook.h:156:14: warning:   by 'bool cbAuiNotebook::InsertPage(size_t, wxWindow*, const wxString&, bool, const wxBitmap&)' [-Woverloaded-virtual]
         bool InsertPage(size_t page_idx,
              ^

Maybe, we need to fix our C::B's source :)

Any one know how to remove such warning?
I see in our cbauibook.h, we have:
Code
class DLLIMPORT cbAuiNotebook : public wxAuiNotebook
{
    public:
...
        /** \brief Add Page
         *
         * Calls the base-class function and after that
         * MinmizeFreeSpace().
         * \param page The page to add
         * \param caption The caption of the page
         * \param select If true the page gets selected
         * \param bitmap The bitmap of the tab
         * \return true if successfull
         */
        bool AddPage(wxWindow* page,
                     const wxString& caption,
                     bool select = false,
                     const wxBitmap& bitmap = wxNullBitmap);
...

And in wx's auibook.h, it has:
Code
class WXDLLIMPEXP_AUI wxAuiNotebook : public wxNavigationEnabled<wxBookCtrlBase>
{

public:

    wxAuiNotebook() { Init(); }

    wxAuiNotebook(wxWindow* parent,
                  wxWindowID id = wxID_ANY,
                  const wxPoint& pos = wxDefaultPosition,
                  const wxSize& size = wxDefaultSize,
                  long style = wxAUI_NB_DEFAULT_STYLE)
    {
        Init();
        Create(parent, id, pos, size, style);
    }

    virtual ~wxAuiNotebook();

    bool Create(wxWindow* parent,
                wxWindowID id = wxID_ANY,
                const wxPoint& pos = wxDefaultPosition,
                const wxSize& size = wxDefaultSize,
                long style = 0);

    void SetWindowStyleFlag(long style);
    void SetArtProvider(wxAuiTabArt* art);
    wxAuiTabArt* GetArtProvider() const;

    virtual void SetUniformBitmapSize(const wxSize& size);
    virtual void SetTabCtrlHeight(int height);

    bool AddPage(wxWindow* page,
                 const wxString& caption,
                 bool select = false,
                 const wxBitmap& bitmap = wxNullBitmap);

    bool InsertPage(size_t pageIdx,
                    wxWindow* page,
                    const wxString& caption,
                    bool select = false,
                    const wxBitmap& bitmap = wxNullBitmap);

    bool DeletePage(size_t page);
    bool RemovePage(size_t page);

    virtual size_t GetPageCount() const;
    virtual wxWindow* GetPage(size_t pageIdx) const;
    int GetPageIndex(wxWindow* pageWnd) const;

    bool SetPageText(size_t page, const wxString& text);
    wxString GetPageText(size_t pageIdx) const;

    bool SetPageToolTip(size_t page, const wxString& text);
    wxString GetPageToolTip(size_t pageIdx) const;

    bool SetPageBitmap(size_t page, const wxBitmap& bitmap);
    wxBitmap GetPageBitmap(size_t pageIdx) const;

    int SetSelection(size_t newPage);
    int GetSelection() const;

    virtual void Split(size_t page, int direction);

    const wxAuiManager& GetAuiManager() const { return m_mgr; }

    // Sets the normal font
    void SetNormalFont(const wxFont& font);

    // Sets the selected tab font
    void SetSelectedFont(const wxFont& font);

    // Sets the measuring font
    void SetMeasuringFont(const wxFont& font);

    // Sets the tab font
    virtual bool SetFont(const wxFont& font);

    // Gets the tab control height
    int GetTabCtrlHeight() const;

    // Gets the height of the notebook for a given page height
    int GetHeightForPageHeight(int pageHeight);

    // Shows the window menu
    bool ShowWindowMenu();

    // we do have multiple pages
    virtual bool HasMultiplePages() const { return true; }

    // we don't want focus for ourselves
    // virtual bool AcceptsFocus() const { return false; }

    //wxBookCtrlBase functions

    virtual void SetPageSize (const wxSize &size);
    virtual int  HitTest (const wxPoint &pt, long *flags=NULL) const;

    virtual int GetPageImage(size_t n) const;
    virtual bool SetPageImage(size_t n, int imageId);

    virtual int ChangeSelection(size_t n);

    virtual bool AddPage(wxWindow *page, const wxString &text, bool select,
                         int imageId);
    virtual bool DeleteAllPages();
    virtual bool InsertPage(size_t index, wxWindow *page, const wxString &text,
                            bool select, int imageId);

The interesting thing is, in wx's wxAuiNotebook, it has two function declarations named AddPage:
Code
    bool AddPage(wxWindow* page,
                 const wxString& caption,
                 bool select = false,
                 const wxBitmap& bitmap = wxNullBitmap);

and

    virtual bool AddPage(wxWindow *page, const wxString &text, bool select,
                         int imageId);

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: Bat on November 07, 2015, 05:32:33 pm
I get clean version from SVN, build with Wx 2.8.12, mingw32-g++ (tdm-1) 4.7.1, it fail with :

Code
In file included from D:\bat\data\program\gcc\codeblocks_clean\src\sdk\scrollingdialog.cpp:17:0:
include/scrollingdialog.h:162:34: error: expected initializer before ':' token

Code
D:\bat\data\program\gcc\codeblocks_clean\src\src\infopane.cpp:39:1: error: definition of static data member 'InfoPane::sm_eventTable' of dllimport'd class

Code
include/cbauibook.h:29:31: error: expected initializer before ':' token

Code
..\..\..\include/cbstyledtextctrl.h:20:34: error: expected initializer before ':' token

If I removed DLLIMPORT in theses location, it build (and works).
I haven't trace why it's give error here and not elsewhere

Is my compiler and or wx too old ?

Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on November 07, 2015, 06:10:19 pm
I get clean version from SVN, build with Wx 2.8.12, mingw32-g++ (tdm-1) 4.7.1, it fail with :

Does Code::Blocks SVN r10560 fix the issue?

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: Bat on November 07, 2015, 06:50:34 pm
Yes I tried with r10561 and it's ok
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on November 08, 2015, 09:44:43 am
it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 08, 2015, 12:16:05 pm
it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)
Please give use details about your problem.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on November 08, 2015, 12:29:25 pm
...
Any one know how to remove such warning?
...
You have to add a using directive for the function in the parent class. If our function does something special and using the original function is not a good idea you can put the using directive in the private/protected section.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 09, 2015, 06:11:55 am
Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.
Yes, I know and I say this is the wrong way to do it.
All these libs have not been designed to be shared libraries.
If they are we should just build them as such and don't bother with all this trickery.

Also on linux using the default visibility can cause lots of problems and strange crashes.
As you suggested, we need to build them as static libraries, and we need to link them as static libraries. A lot of targets need those static libraries, for example, if some plugin need to access the configure file, then we need to link to the static version of the tinyxml library.
Am I right?
If we see this is the correct direction, I may take some time to test it.
OK.
I have done the patches, which let some plugins link to the static library. So the symbols in those static libraries are not exported from the codeblocks.dll, see the patches here: Link (https://sourceforge.net/p/codeblocks/tickets/239/#bd97)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on November 09, 2015, 07:55:56 am
it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)
Please give use details about your problem.
thanks reply,and here is
Quote
C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 09, 2015, 08:24:54 am
Quote
C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?
Show us the full build log please. See:FAQ-Compiling (errors) - CodeBlocks (http://wiki.codeblocks.org/index.php/FAQ-Compiling_(errors)#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 11, 2015, 03:33:31 pm
...
OK.
I have done the patches, which let some plugins link to the static library. So the symbols in those static libraries are not exported from the codeblocks.dll, see the patches here: Link (https://sourceforge.net/p/codeblocks/tickets/239/#bd97)
I see a crash here with the above patches:
Code
[debug]> bt 30
[debug]#0  0x004c2f21 in sq_getprintfunc (v=0x0) at F:\cb_sf_git\trunk\src\sdk\scripting\squirrel\sqapi.cpp:1256
[debug]#1  0x0049e1cc in ScriptConsole::ScriptConsole (this=0x74587d8, parent=0x5a0bd00, id=-1) at F:\cb_sf_git\trunk\src\src\scriptconsole.cpp:116
[debug]#2  0x00451844 in MainFrame::CreateIDE (this=0x5a0bd00) at F:\cb_sf_git\trunk\src\src\main.cpp:756
[debug]#3  0x0044f847 in MainFrame::MainFrame (this=0x5a0bd00, parent=0x0) at F:\cb_sf_git\trunk\src\src\main.cpp:602
[debug]#4  0x00402a56 in CodeBlocksApp::InitFrame (this=0x587d4c0) at F:\cb_sf_git\trunk\src\src\app.cpp:489
[debug]#5  0x0040407b in CodeBlocksApp::OnInit (this=0x587d4c0) at F:\cb_sf_git\trunk\src\src\app.cpp:697
[debug]#6  0x004fb06e in wxAppConsoleBase::CallOnInit (this=0x587d4c0) at D:\wx3\include\wx\app.h:93
[debug]#7  0x6a00fbf0 in wxEntryReal (argc=@0x6abe53f8: 9, argv=0x587d150) at D:\wx3\src\common\init.cpp:479
[debug]#8  0x6a094b98 in wxEntry (argc=@0x6abe53f8: 9, argv=0x587d150) at D:\wx3\src\msw\main.cpp:197
[debug]#9  0x6a094e86 in wxEntry (hInstance=0x400000, nCmdShow=10) at D:\wx3\src\msw\main.cpp:415
[debug]#10 0x0040224d in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0, nCmdShow=10) at F:\cb_sf_git\trunk\src\src\app.cpp:322
[debug]#11 0x0052ac9d in main ()
[debug]>>>>>>cb_gdb:

Here:
Code
ScriptConsole::ScriptConsole(wxWindow* parent,wxWindowID id)
{
    //(*Initialize(ScriptConsole)
    wxBoxSizer* BoxSizer2;
    wxBoxSizer* BoxSizer1;

    Create(parent, id, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL, _T("id"));
    BoxSizer1 = new wxBoxSizer(wxVERTICAL);
    txtConsole = new wxTextCtrl(this, ID_TEXTCTRL1, wxEmptyString, wxDefaultPosition, wxDefaultSize, wxTE_MULTILINE|wxTE_READONLY|wxHSCROLL, wxDefaultValidator, _T("ID_TEXTCTRL1"));
    wxFont txtConsoleFont(10,wxFONTFAMILY_MODERN,wxFONTSTYLE_NORMAL,wxFONTWEIGHT_NORMAL,false,wxEmptyString,wxFONTENCODING_DEFAULT);
    txtConsole->SetFont(txtConsoleFont);
    BoxSizer1->Add(txtConsole, 1, wxALL|wxEXPAND, 0);
    Panel1 = new wxPanel(this, ID_PANEL1, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL, _T("ID_PANEL1"));
    Panel1->SetBackgroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE));
    BoxSizer2 = new wxBoxSizer(wxHORIZONTAL);
    lblCommand = new wxStaticText(Panel1, ID_STATICTEXT1, _("Command:"), wxDefaultPosition, wxDefaultSize, 0, _T("ID_STATICTEXT1"));
    BoxSizer2->Add(lblCommand, 0, wxALL|wxALIGN_CENTER_VERTICAL, 5);
    txtCommand = new wxComboBox(Panel1, ID_COMBOBOX1, wxEmptyString, wxDefaultPosition, wxDefaultSize, 0, 0, wxCB_DROPDOWN|wxTE_PROCESS_ENTER, wxDefaultValidator, _T("ID_COMBOBOX1"));
    wxFont txtCommandFont(10,wxFONTFAMILY_MODERN,wxFONTSTYLE_NORMAL,wxFONTWEIGHT_NORMAL,false,wxEmptyString,wxFONTENCODING_DEFAULT);
    txtCommand->SetFont(txtCommandFont);
    BoxSizer2->Add(txtCommand, 1, wxALL|wxALIGN_CENTER_VERTICAL, 0);
    btnExecute = new wxBitmapButton(Panel1, ID_BITMAPBUTTON1, wxArtProvider::GetBitmap(wxART_MAKE_ART_ID_FROM_STR(_T("wxART_EXECUTABLE_FILE")),wxART_BUTTON), wxDefaultPosition, wxDefaultSize, wxBU_AUTODRAW, wxDefaultValidator, _T("ID_BITMAPBUTTON1"));
    btnExecute->SetToolTip(_("Execute current command"));
    BoxSizer2->Add(btnExecute, 0, wxALIGN_CENTER_VERTICAL, 5);
    btnLoad = new wxBitmapButton(Panel1, ID_BITMAPBUTTON2, wxArtProvider::GetBitmap(wxART_MAKE_ART_ID_FROM_STR(_T("wxART_FILE_OPEN")),wxART_BUTTON), wxDefaultPosition, wxDefaultSize, wxBU_AUTODRAW, wxDefaultValidator, _T("ID_BITMAPBUTTON2"));
    btnLoad->SetDefault();
    btnLoad->SetToolTip(_("Load from file"));
    BoxSizer2->Add(btnLoad, 0, wxALL|wxALIGN_CENTER_VERTICAL, 0);
    btnClear = new wxBitmapButton(Panel1, ID_BITMAPBUTTON3, wxArtProvider::GetBitmap(wxART_MAKE_ART_ID_FROM_STR(_T("wxART_DELETE")),wxART_BUTTON), wxDefaultPosition, wxDefaultSize, wxBU_AUTODRAW, wxDefaultValidator, _T("ID_BITMAPBUTTON3"));
    btnClear->SetDefault();
    btnClear->SetToolTip(_("Clear output window"));
    BoxSizer2->Add(btnClear, 0, wxALL|wxALIGN_CENTER_VERTICAL, 0);
    Panel1->SetSizer(BoxSizer2);
    BoxSizer2->Fit(Panel1);
    BoxSizer2->SetSizeHints(Panel1);
    BoxSizer1->Add(Panel1, 0, wxALL|wxEXPAND, 0);
    SetSizer(BoxSizer1);
    BoxSizer1->Fit(this);
    BoxSizer1->SetSizeHints(this);

    Connect(ID_COMBOBOX1,wxEVT_COMMAND_TEXT_ENTER,(wxObjectEventFunction)&ScriptConsole::OnbtnExecuteClick);
    Connect(ID_BITMAPBUTTON1,wxEVT_COMMAND_BUTTON_CLICKED,(wxObjectEventFunction)&ScriptConsole::OnbtnExecuteClick);
    Connect(ID_BITMAPBUTTON2,wxEVT_COMMAND_BUTTON_CLICKED,(wxObjectEventFunction)&ScriptConsole::OnbtnLoadClick);
    Connect(ID_BITMAPBUTTON3,wxEVT_COMMAND_BUTTON_CLICKED,(wxObjectEventFunction)&ScriptConsole::OnbtnClearClick);
    //*)

    txtCommand->Append(wxEmptyString);
    if (!s_Console)
    {
        s_Console = this;
        s_OldPrintFunc = sq_getprintfunc(SquirrelVM::GetVMPtr());
        sq_setprintfunc(SquirrelVM::GetVMPtr(), ScriptConsolePrintFunc);
    }

    Log(_("Welcome to the script console!"));
}

I see that SquirrelVM::GetVMPtr() is 0 here.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 11, 2015, 04:11:42 pm
...
I see that SquirrelVM::GetVMPtr() is 0 here.
I debugged for a while, and I found that the SquirrelVM::_VM is a static variable of the class.
Code
class SquirrelVM
{
friend class SquirrelObject;
friend struct SquirrelError;
public:
    // C::B patch: Add additional initilisation flags
static void Init(SquirrelInitFlags flags = sqifAll);
static BOOL_T IsInitialized(){return _VM == NULL?FALSE:TRUE;}
static void Shutdown();
static void Cleanup();
static BOOL_T Update(); //debugger and maybe GC later
static SquirrelObject CompileScript(const SQChar *s);
static SquirrelObject CompileBuffer(const SQChar *s,const SQChar * debugInfo=sqT("console_buffer"));
static SquirrelObject RunScript(const SquirrelObject &o,SquirrelObject *_this = NULL);
static void PrintFunc(HSQUIRRELVM v,const SQChar* s,...);
static BOOL_T BeginCall(const SquirrelObject &func);
static BOOL_T BeginCall(const SquirrelObject &func,SquirrelObject &_this);
static void PushParam(const SquirrelObject &o);
static void PushParam(const SQChar *s);
static void PushParam(SQInteger n);
static void PushParam(SQFloat f);
static void PushParam(SQUserPointer up);
static void PushParamNull();
static SquirrelObject EndCall();
static SquirrelObject CreateString(const SQChar *s);
static SquirrelObject CreateTable();
static SquirrelObject CreateArray(SQInteger size);
static SquirrelObject CreateInstance(SquirrelObject &oclass); // oclass is an existing class. Create an 'instance' (OT_INSTANCE) of oclass.
static SquirrelObject CreateFunction(SQFUNCTION func);
  static SquirrelObject CreateUserData(SQInteger size);

static const SquirrelObject &GetRootTable();
static HSQUIRRELVM GetVMPtr() { return _VM; }

#if 0
  static void SetVMPtr(HSQUIRRELVM v) {
    _VM = v;
  } // setVMPtr
#endif

  static void GetVMSys(SquirrelVMSys & vmSys) {
    vmSys._VM   = _VM;
    vmSys._root = _root;
  } // GetVMSys

  static void SetVMSys(const SquirrelVMSys & vmSys) {
    _VM   = vmSys._VM;
    _root = vmSys._root;
  } // SetVMSys

  static void PushValue(INT_T val) {
    sq_pushinteger(_VM,val);
  } // PushValue
  static void PushValue(FLOAT_T val) {
    sq_pushfloat(_VM,val);
  } // PushValue
  static void PushValue(bool val) { // Compiler treats SQBool as INT_T.
    sq_pushbool(_VM,val);
  } // PushValue
  static void PushValue(SQChar * val) {
    sq_pushstring(_VM,val,-1);
  } // PushValue
  static void PushValue(SQUserPointer val) {
    sq_pushuserpointer(_VM,val);
  } // PushValue
  static void PushValue(const SQChar * val) {
    sq_pushstring(_VM,val,-1);
  } // PushValue
  static void PushObject(SquirrelObject & so) {
    sq_pushobject(_VM,so._o);
  } // PushObject
  static void Pop(SQInteger nelemstopop) {
    sq_pop(_VM,nelemstopop);
  } // Pop
  static void PushRootTable(void);
  // Create/bind a function on the table currently on the stack.
  static SquirrelObject CreateFunction(SQFUNCTION func,const SQChar * scriptFuncName,const SQChar * typeMask=0);
  // Create/bind a function on the table so. typeMask: standard Squirrel types plus: no typemask means no args, "*" means any type of args.
  static SquirrelObject CreateFunction(SquirrelObject & so,SQFUNCTION func,const SQChar * scriptFuncName,const SQChar * typeMask=0);
  // Create/bind a function to the root table. typeMask: standard Squirrel types plus: no typemask means no args, "*" means any type of args.
  static SquirrelObject CreateFunctionGlobal(SQFUNCTION func,const SQChar * scriptFuncName,const SQChar * typeMask=0);

private:
static HSQUIRRELVM _VM;
static SQInteger _CallState;
static SquirrelObject * _root;
};
I see two instance of the SquirrelVM::_VM exists. The first one is initialized inside the sdk target, and the other instance is inside the src target. It looks like the first one get initialized correctly, but the second one is not, so the second one's value is 0, and we get a crash. Is it by design of the compiler? I mean this time, SquirrelVM library is a static library, and its source are copied to both sdk and src...

So, I think we still need the "old" way, I mean that we should have only one instance of the SquirrelVM::_VM, and we need to export the symbols from the sdk.

EDIT:
Is the issue mentioned here: c++ - Initializing private static members - Stack Overflow (http://stackoverflow.com/questions/185844/initializing-private-static-members), each cpp include the class will have a copy of the static member variable?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 12, 2015, 12:52:43 am
...
I see two instance of the SquirrelVM::_VM exists. The first one is initialized inside the sdk target, and the other instance is inside the src target. It looks like the first one get initialized correctly, but the second one is not, so the second one's value is 0, and we get a crash. Is it by design of the compiler? I mean this time, SquirrelVM library is a static library, and its source are copied to both sdk and src...

So, I think we still need the "old" way, I mean that we should have only one instance of the SquirrelVM::_VM, and we need to export the symbols from the sdk.

EDIT:
Is the issue mentioned here: c++ - Initializing private static members - Stack Overflow (http://stackoverflow.com/questions/185844/initializing-private-static-members), each cpp include the class will have a copy of the static member variable?
OK, this is the actual issue to my problem: c++ - Using static members across Static Lib and DLL - member value is resetting - Stack Overflow (http://stackoverflow.com/questions/12991581/using-static-members-across-static-lib-and-dll-member-value-is-resetting), the static lib which contains some static member should only be linked to one dll.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on November 12, 2015, 06:10:14 am
Quote
C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?
Show us the full build log please. See:FAQ-Compiling (errors) - CodeBlocks (http://wiki.codeblocks.org/index.php/FAQ-Compiling_(errors)#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
sorry,here it is.it is huge,so i post a 7z file
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on November 12, 2015, 06:33:06 am
Code
g++.exe -Wall -g -pipe -mthreads -m64 -fno-keep-inline-dllexport -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -D_WIN64 -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -std=c++11 -IC:\localusr\wxWidgets\include -IC:\localusr\wxWidgets\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c E:\Devel\Codeblocks\trunk\src\sdk\xtra_res.cpp -o .objs30_64\sdk\xtra_res.o
                 from E:\Devel\Codeblocks\trunk\src\sdk\searchresultslog.cpp:15:
C:\localusr\wxWidgets\include/wx/window.h:1872:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
g++.exe -shared  -Wl,--out-implib=devel30_64\libcodeblocks.a -Wl,--dll -Lbase\tinyxml -LC:\localusr\wxWidgets\lib\gcc_dll -Ldevel30_64 -Lsdk\scripting\lib .objs30_64\sdk\configmanager-revision.o .objs30_64\base\tinyxml\tinywxuni.o .objs30_64\sdk\annoyingdialog.o .objs30_64\sdk\autodetectcompilers.o .objs30_64\sdk\base64.o .objs30_64\sdk\blockallocated.o .objs30_64\sdk\cbauibook.o .objs30_64\sdk\cbcolourmanager.o .objs30_64\sdk\cbdebugger_interfaces.o .objs30_64\sdk\cbeditor.o .objs30_64\sdk\cbeditorprintout.o .objs30_64\sdk\cbexception.o .objs30_64\sdk\cbplugin.o .objs30_64\sdk\cbproject.o .objs30_64\sdk\cbstatusbar.o .objs30_64\sdk\cbstyledtextctrl.o .objs30_64\sdk\cbthreadpool.o .objs30_64\sdk\cbtreectrl.o .objs30_64\sdk\cbworkspace.o .objs30_64\sdk\ccmanager.o .objs30_64\sdk\compileoptionsbase.o .objs30_64\sdk\compiler.o .objs30_64\sdk\compilercommandgenerator.o .objs30_64\sdk\compilerfactory.o .objs30_64\sdk\compileroptions.o .objs30_64\sdk\compiletargetbase.o .objs30_64\sdk\configmanager.o .objs30_64\sdk\configurationpanel.o .objs30_64\sdk\configuretoolsdlg.o .objs30_64\sdk\confirmreplacedlg.o .objs30_64\sdk\crc32.o .objs30_64\sdk\debuggermanager.o .objs30_64\sdk\editarrayfiledlg.o .objs30_64\sdk\editarrayorderdlg.o .objs30_64\sdk\editarraystringdlg.o .objs30_64\sdk\editor_hooks.o .objs30_64\sdk\editorbase.o .objs30_64\sdk\editorcolourset.o .objs30_64\sdk\editorlexerloader.o .objs30_64\sdk\editormanager.o .objs30_64\sdk\editpairdlg.o .objs30_64\sdk\editpathdlg.o .objs30_64\sdk\edittooldlg.o .objs30_64\sdk\encodingdetector.o .objs30_64\sdk\externaldepsdlg.o .objs30_64\sdk\filefilters.o .objs30_64\sdk\filegroupsandmasks.o .objs30_64\sdk\filemanager.o .objs30_64\sdk\findreplacedlg.o .objs30_64\sdk\genericmultilinenotesdlg.o .objs30_64\sdk\globals.o .objs30_64\sdk\importers_globals.o .objs30_64\sdk\incrementalselectlistdlg.o .objs30_64\sdk\infowindow.o .objs30_64\sdk\loggers.o .objs30_64\sdk\logmanager.o .objs30_64\sdk\macrosmanager.o .objs30_64\sdk\managedthread.o .objs30_64\sdk\manager.o .objs30_64\sdk\menuitemsmanager.o .objs30_64\sdk\mozilla_chardet\src\CharDistribution.o .objs30_64\sdk\mozilla_chardet\src\JpCntx.o .objs30_64\sdk\mozilla_chardet\src\LangBulgarianModel.o .objs30_64\sdk\mozilla_chardet\src\LangCyrillicModel.o .objs30_64\sdk\mozilla_chardet\src\LangGreekModel.o .objs30_64\sdk\mozilla_chardet\src\LangHebrewModel.o .objs30_64\sdk\mozilla_chardet\src\LangHungarianModel.o .objs30_64\sdk\mozilla_chardet\src\LangThaiModel.o .objs30_64\sdk\mozilla_chardet\src\nsBig5Prober.o .objs30_64\sdk\mozilla_chardet\src\nsCharSetProber.o .objs30_64\sdk\mozilla_chardet\src\nsEscCharsetProber.o .objs30_64\sdk\mozilla_chardet\src\nsEscSM.o .objs30_64\sdk\mozilla_chardet\src\nsEUCJPProber.o .objs30_64\sdk\mozilla_chardet\src\nsEUCKRProber.o .objs30_64\sdk\mozilla_chardet\src\nsEUCTWProber.o .objs30_64\sdk\mozilla_chardet\src\nsGB2312Prober.o .objs30_64\sdk\mozilla_chardet\src\nsHebrewProber.o .objs30_64\sdk\mozilla_chardet\src\nsLatin1Prober.o .objs30_64\sdk\mozilla_chardet\src\nsMBCSGroupProber.o .objs30_64\sdk\mozilla_chardet\src\nsMBCSSM.o .objs30_64\sdk\mozilla_chardet\src\nsSBCharSetProber.o .objs30_64\sdk\mozilla_chardet\src\nsSBCSGroupProber.o .objs30_64\sdk\mozilla_chardet\src\nsSJISProber.o .objs30_64\sdk\mozilla_chardet\src\nsUniversalDetector.o .objs30_64\sdk\mozilla_chardet\src\nsUTF8Prober.o .objs30_64\sdk\multiselectdlg.o .objs30_64\sdk\newfromtemplatedlg.o .objs30_64\sdk\personalitymanager.o .objs30_64\sdk\pipedprocess.o .objs30_64\sdk\pluginmanager.o .objs30_64\sdk\pluginsconfigurationdlg.o .objs30_64\sdk\printing_types.o .objs30_64\sdk\projectbuildtarget.o .objs30_64\sdk\projectfile.o .objs30_64\sdk\projectfileoptionsdlg.o .objs30_64\sdk\projectlayoutloader.o .objs30_64\sdk\projectloader.o .objs30_64\sdk\projectloader_hooks.o .objs30_64\sdk\projectmanager.o .objs30_64\sdk\projectsfilemasksdlg.o .objs30_64\sdk\projecttemplateloader.o .objs30_64\sdk\scripting\bindings\sc_consts.o .objs30_64\sdk\scripting\bindings\sc_dialog.o .objs30_64\sdk\scripting\bindings\sc_globals.o .objs30_64\sdk\scripting\bindings\sc_io.o .objs30_64\sdk\scripting\bindings\sc_plugin.o .objs30_64\sdk\scripting\bindings\sc_progress.o .objs30_64\sdk\scripting\bindings\sc_util_dialogs.o .objs30_64\sdk\scripting\bindings\sc_wxtypes.o .objs30_64\sdk\scripting\bindings\scriptbindings.o .objs30_64\sdk\scriptingmanager.o .objs30_64\sdk\scriptsecuritywarningdlg.o .objs30_64\sdk\scrollingdialog.o .objs30_64\sdk\sdk_events.o .objs30_64\sdk\searchresultslog.o .objs30_64\sdk\selecttargetdlg.o .objs30_64\sdk\templatemanager.o .objs30_64\sdk\toolsmanager.o .objs30_64\sdk\uservarmanager.o .objs30_64\sdk\workspaceloader.o .objs30_64\sdk\xtra_res.o  -o devel30_64\codeblocks.dll -Wl,--enable-auto-image-base -Wl,--export-all-symbols -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined  -lshfolder -ltxml30_64 -lwxscintilla_cb -lsqplus30_64 -lsqstdlib30_64 -lsquirrel30_64 -lgdi32 -lwxmsw30u

Likely error caused by this option; -std=c++11! Windows and wxWidgets 3.0 needs some GNU compiler options to work.

Edit: I used the option of defining "HAVE_TR1_TYPE_TRAITS"; but, the normal way is to use gnu++11 instead of c++11 as the standard.
Edit2: If using an MinGW64 GCC; I would try the defining of HAVE_TR1_TYPE_TRAITS. But, I am NOT sure what version of MinGW64 GCC supported what that defines means; I am using MSys2 MinGW64 GCC 5.2.0 and defining HAVE_TR1_TYPE_TRAITS while building wxWidgets and Code::Blocks gets read of the error.

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on November 12, 2015, 06:38:50 am
Quote
C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?
Show us the full build log please. See:FAQ-Compiling (errors) - CodeBlocks (http://wiki.codeblocks.org/index.php/FAQ-Compiling_(errors)#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
sorry,here it is.it is huge,so i post a 7z file
Hi, I see this log file, and I don't see something is wrong from the log file.
But it has reported before in our forum:
Build C::B linker error: undefined reference to`wxMSLU__wstat(wchar_t const*,... (http://forums.codeblocks.org/index.php/topic,19779.msg135153.html#msg135153), either a compiler issue or wx build option issue.
Also, I see some similar page which is in Japaneses state the issue, see:
wxWidgets-2.9.5 msw - なんとな~くしあわせ?の日記 (http://nantonaku-shiawase.hatenablog.com/entry/2013/08/17/081354), you may need to translate to English language by some web service.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: stahta01 on November 19, 2015, 08:05:02 pm
Just found the cause of a two wxWidgets Debug Alert I have been getting for a few days.

Code
../../src/common/filefn.cpp(253): assert "!fn.IsDir()" failed in FindValidPath(): Cannot search for directories; only for files

Code
../../src/common/arrstr.cpp(395): assert "iIndex != (-1)" failed in Remove(): removing inexistent element in wxArrayString::Remove

I was having a random issue with Using the CygWin compiler when the GCC compiler was the default compiler.
So, I changed the "default compiler" to "No Compiler", the random issue went away.
But, it cause the two messages above when starting my self built Code::Blocks using MinGW64 32bit GCC 5.2 and wx3.0.2

Tim S.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on November 23, 2015, 02:18:44 am
Can you post backtraces?
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on November 26, 2015, 09:25:46 am
Quote
C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?
Show us the full build log please. See:FAQ-Compiling (errors) - CodeBlocks (http://wiki.codeblocks.org/index.php/FAQ-Compiling_(errors)#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
sorry,here it is.it is huge,so i post a 7z file
Hi, I see this log file, and I don't see something is wrong from the log file.
But it has reported before in our forum:
Build C::B linker error: undefined reference to`wxMSLU__wstat(wchar_t const*,... (http://forums.codeblocks.org/index.php/topic,19779.msg135153.html#msg135153), either a compiler issue or wx build option issue.
Also, I see some similar page which is in Japaneses state the issue, see:
wxWidgets-2.9.5 msw - なんとな~くしあわせ?の日記 (http://nantonaku-shiawase.hatenablog.com/entry/2013/08/17/081354), you may need to translate to English language by some web service.
thx ,i take a look and try later!
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: mageia on November 26, 2015, 10:30:51 am
thanks again for ollydbg's time and patience,it works
iin my case i think the key is the first link and i modify wxwidgets 3.02's config.gcc,the second link sound like set gnu++11 on and i already done
//
# Standard flags for C++
CXXFLAGS=-std=gnu++11 -fpermissive -Wno-unused-local-typedefs -fno-keep-inline-dllexport
# Standard preprocessor flags (common for CC and CXX)
CPPFLAGS ?= -DHAVE_TR1_TYPE_TRAITS
//
and build wxwidgets and codeblocks,and it works
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on December 06, 2015, 08:20:01 am
...
Any one know how to remove such warning?
...
You have to add a using directive for the function in the parent class. If our function does something special and using the original function is not a good idea you can put the using directive in the private/protected section.
This patch can fix the warning:
Code
diff --git a/src/include/cbauibook.h b/src/include/cbauibook.h
index a32ad7a..52aabd5 100644
--- a/src/include/cbauibook.h
+++ b/src/include/cbauibook.h
@@ -393,6 +393,11 @@ class DLLIMPORT cbAuiNotebook : public wxAuiNotebook
          */
         static int s_advanceDirection;
 
+    private:
+        // the following two using directives remove the "-Woverloaded-virtual" warnings
+        using wxAuiNotebook::AddPage;
+        using wxAuiNotebook::InsertPage;
+
         DECLARE_EVENT_TABLE()
 };
OK to commit?
Question: do I need to add a "#if wxCHECK_VERSION(3,0,0)" check?
I just checked the wx-2.8.12's include\wx\aui\auibook.h, I don't see the virtual function named AddPage there. Instead, I see two overload functions:
Code
    bool AddPage(wxWindow* page, const wxAuiNotebookPage& info);
....
    bool AddPage(wxWindow* page,
                 const wxString& caption,
                 bool select = false,
                 const wxBitmap& bitmap = wxNullBitmap);
...
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: oBFusCATed on December 06, 2015, 06:49:46 pm
Should be safe to commit I think, it doesn't even change the ABI.

Also I think you don't have to add checks for wx3.0, because I think that I've seen this warning with wx2.8.
Title: Re: Build C::B against wx3.02 with gcc 5.2 under Windows
Post by: ollydbg on July 03, 2016, 03:19:54 am
Some news about the crash issue: sounds like an optimizer issue of GCC, see Re: SVN build crashes when trying to editing/adding new compiler flags (http://forums.codeblocks.org/index.php/topic,21207.msg145359.html#msg145359)