Author Topic: Build C::B against wx3.02 with gcc 5.2 under Windows  (Read 85032 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #75 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.
« Last Edit: October 14, 2015, 01:29:47 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #76 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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7589
    • My Best Post
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #77 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.

C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #78 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #79 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).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #80 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, 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.  :(
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #81 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+.
     */
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #82 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, it looks like someone has already done that:

Re: Compiling wxWidgets
Or
MINGW-packages/wxWidgets-3.0.0-gcc-codelight.patch at master ยท Alexpux/MINGW-packages

This does not export the unnecessary symbol, and reduce the wx's dll size, also it can app's improve the startup time.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #83 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #84 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

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 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #85 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline mageia

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #86 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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #87 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #88 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

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline mageia

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #89 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~~~