Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Build C::B against wx3.02 with gcc 5.2 under Windows
stahta01:
--- Quote from: ollydbg on October 05, 2015, 03:26:05 am ---
--- Quote from: 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.
--- End quote ---
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]
...
--- End code ---
--- End quote ---
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:
--- Quote from: stahta01 on October 05, 2015, 12:46:52 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).
--- End quote ---
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.
--- 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.
--- End quote ---
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:
--- Quote from: ollydbg on October 05, 2015, 04:30:46 pm ---
--- Quote from: stahta01 on October 05, 2015, 12:46:52 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).
--- End quote ---
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.
--- 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.
--- End quote ---
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
--- End quote ---
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:
--- Quote from: ollydbg on October 05, 2015, 04:30:46 pm ---
--- 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.
--- End quote ---
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
--- End quote ---
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:
--- Quote from: stahta01 on October 06, 2015, 01:44:20 am ---
--- Quote from: ollydbg on October 05, 2015, 04:30:46 pm ---
--- 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.
--- End quote ---
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
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version