News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

compile issue with wx 3.1.6

Started by kipade, September 19, 2021, 02:52:24 PM

Previous topic - Next topic

kipade

When I update my wx into latest 3.1.6 version, codeblocks could not be compiled any more, because a c++ issue:

n file included from /usr/include/wx-3.1/wx/wx.h:24,
                 from /usr/include/wx-3.1/wx/wxprec.h:42,
                 from ../../../src/include/sdk_common.h:24,
                 from ../../../src/include/sdk_precomp.h:13:
/usr/include/wx-3.1/wx/event.h: In instantiation of 'constexpr auto wxPrivate::DoCast(void (C::*)(E&)) [with E = wxHtmlLinkEvent; C = CCManager]':
../../../src/sdk/ccmanager.cpp:290:22:   required from here
/usr/include/wx-3.1/wx/event.h:157:12: error: 'wxEvtHandler' is an inaccessible base of 'CCManager'
  157 |     return static_cast<void (wxEvtHandler::*)(E&)>(pmf);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


But, the CCManager DO is the child class of wxEvtHandler. How to fix this compile issue?
/usr/include/wx-3.1/wx/event.h:157:12: note:    in pointer to member function conversion


AndrewCot

Are you using the latest SVN trunc code?
If yes, when did you grab the code?
If not try the very latest CF SVN code as it has changes for 3.1.6 from a few weeks ago.

If the latest truck codes  does not help , then comi9ler are you using? Version and the URL you used to download it from?

When did you grab the 3.1.6 Github sources to do the build?


kipade

#2
I think it should be.
I always keep it fresh from https://github.com/obfuscated/codeblocks_sf.git. and from its latest commit log, its equal as svn 12529.
and my OS is ArchLinux, gcc version 11.1.0
thanks

Miguel Gimenez

#3
Works OK with C::B trunk, wxWidgets head and MinGW 8.1 on MSW.

EDIT: may be related to this bug in GCC. Also related to this wxWidgets ticket, fixed 5 years ago.

stahta01

From https://www.gnu.org/software/gcc/gcc-11/changes.html

QuoteThe default mode for C++ is now -std=gnu++17 instead of -std=gnu++14.

You might be having this new issue because of the default change.

I would try using "-std=gnu++14" to see if that fixes the issue.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

kipade

Yes, this option do really works for it. Thanks

Miguel Gimenez

I have just created a ticket on wxWidgets bug tracker.

Miguel Gimenez

#7
@kipade, wxWidgets devs are asking for a quick check, can you do it?. I don't have GCC11.

https://trac.wxwidgets.org/ticket/19266

This is the code to compile:


// This is a compilation-time-only test: just check that a class inheriting
// from wxEvtHandler non-publicly can use Bind() with its method, this used to
// result in compilation errors.
// Note that this test will work only on C++11 compilers, so we test this only
// for such compilers.
#if __cplusplus >= 201103
class HandlerNonPublic : protected wxEvtHandler
{
public:
    HandlerNonPublic()
    {
        Bind(wxEVT_IDLE, &HandlerNonPublic::OnIdle, this);
    }

    void OnIdle(wxIdleEvent&) { }
};
#endif // C++11


EDIT: You can use the attached minimal wxWidgets project, it includes the code above. It is a MSW project, but can be easily adapted to Linux.

Miguel Gimenez

There is another question in the ticket about the output of this code:


#include <iostream>

int main()
{
    std::cout << "__cplusplus= " << __cplusplus << std::endl;
    return (int)__cplusplus;
}


Miguel Gimenez

The solution for this issue is Use Bind() instead of Connect(), as indicated in this wxWidgets ticket.

Following the ticket, documentation for Connect() has been updated to remark that it can be used only with methods of classes publicly inheriting from wxEvtHandler. CCManager derives privately from wxEvtHandler, so it should be modified to use Bind() or change visibility of wxEvtHandler.

I will try to make a patch this week using the first option.

ollydbg

This is fixed in the trunk now, thanks!
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.