Build C::B against wx3.02 with gcc 5.2 under Windows

[stahta01]

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.

[ollydbg]

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 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.

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

[MortenMacFly]

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 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.

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

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.

[stahta01]

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

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.

[ollydbg]

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

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:

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.

[stahta01]

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.

[ollydbg]

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 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
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.

[ollydbg]

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. 

[ollydbg]

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.

[ollydbg]

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)

[stahta01]

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.

[ollydbg]

1. Did you make sure the warning "-Winvalid-pch" is set?

Yes, this option is on the project level.

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.

[ollydbg]

Hi, Tim, the problem can be solved.
I just read the document page: Precompiled Headers - Using the GNU Compiler Collection (GCC)
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:

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. 

[ollydbg]

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)

[stahta01]

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.