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

Offline ollydbg

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

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.


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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #92 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...
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #93 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?
(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: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #94 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 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.
« Last Edit: October 30, 2015, 02:15:51 pm 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: 13406
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #95 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.
(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: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #96 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, this won't change any build target. What's your opinion?
« Last Edit: November 06, 2015, 02:11:54 pm 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: 13406
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #97 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.
(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: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #98 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. :)
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: 13406
    • Travis build status
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #99 on: November 07, 2015, 12:24:00 pm »
Why do you need to export the InfoPane class?
(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: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #100 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.
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: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #101 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);

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 Bat

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


Offline stahta01

  • Lives here!
  • ****
  • Posts: 7785
    • My Best Post
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #103 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.
C Programmer working to learn more about C++ and Git.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Bat

  • Multiple posting newcomer
  • *
  • Posts: 48
Re: Build C::B against wx3.02 with gcc 5.2 under Windows
« Reply #104 on: November 07, 2015, 06:50:34 pm »
Yes I tried with r10561 and it's ok