Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
These are the changes mentioned by stahta01. The original macro definition was

Code: [Select]
#define WX_DECLARE_OBJARRAY_WITH_DECL(T, name, decl) \
    typedef T _wxObjArray##name;                            \
    _WX_DECLARE_OBJARRAY(_wxObjArray##name, name, wxArrayPtrVoid, decl)

and the current is

Code: [Select]
#define WX_DECLARE_OBJARRAY_WITH_DECL(T, name, classdecl)                     \
    classdecl wxObjectArrayTraitsFor##name                                    \
    {                                                                         \
    public:                                                                   \
        static T* Clone(const T& item);                                       \
        static void Free(T* p);                                               \
    };                                                                        \
    typedef wxBaseObjectArray<T, wxObjectArrayTraitsFor##name>                \
        wxBaseObjectArrayFor##name;                                           \
    typedef int (wxCMPFUNC_CONV *CMPFUNC##T)(T **pItem1, T **pItem2);         \
    classdecl name : public wxBaseObjectArrayFor##name                        \
    {                                                                         \
    public:                                                                   \
        name() : wxBaseObjectArrayFor##name() { }                             \
        name(const name& src) : wxBaseObjectArrayFor##name(src) { }           \
    }

but this comment in wxWidgets docs (see http://docs.wxwidgets.org/trunk/dynarray_8h.html#a015654ccb706038e60295cc202679be3)

Quote
// note: not "MyClass *"!

suggests that

Code: [Select]
WX_DECLARE_USER_EXPORTED_OBJARRAY(wxWindow*, wxWindowPtrArray, WXDLLIMPEXP_FNB);
is incorrect. The original macro definition was tolerant, but the new is not.
52
Starting on Date: 5/31/2018 there was many changes to WX_DECLARE_USER_EXPORTED_OBJARRAY [header file] I think the changes resulted in only classnames being supported instead of pointers to classnames. This is theory I have done nothing to confirm it.

Edit: I have stopped work on this and I am going with the likely problem is in Code::Blocks source code; and, it is beyond me to either fix or definitely confirm that C::B wxContrib code is the real problem.

Tim S.
53
Does not seem to be a missing wxWidgets header include problem.

I did confirm the problem with wxWidgets recent git master and Mingw64 32 bit GCC 8.1.0 compiler.
Now building with an GCC 6.4.0 and wxWidgets recent git master to see if wxWidgets or compiler was the trigger of the issue.

Tim S.
54
That I don't know. I was using mingw 7.1 and an old trunk release of wxWidgets. Which doesn't help much.

I originally had this error trying to compile codeblocks with mingw 7.1 and the new updated trunk build of wxWidgets. I then updated mingw to 8.1 hoping to fix the issue only to get the same message. So it very well could be a wxWidgets issue.

And for whatever reason google drive won't let me upload that file. It gets stuck on "finishing upload" I've uploaded it 3 times with the same result. :(

also, my shift is done, so I won't have access to this computer again until thursday.
55
and yes the wxWidgets version I'm using seems to work fine with my software that I wrote.

I meant if codeblocks builds with a other compiler but the same wx version. Because i think this is a wx issue and not a compiler issue...
56
If you want I could upload my libs to google drive or something.

My compiler has the following selection: i686-8.1.0-posix-sjlj-rt_v6-rev0

edit: it's uploading now. You just nee the mono DLL release and debug builds right?
57
Downloading the win32-sjlj version of Mingw64 gcc 8.1.0; Edited typo in GCC version number.

It will take several hours to build wxWidgets and then build Code::Blocks.

Note: My guess is that the wxWidgets changed an header file; and, the fix is the include a header in Code::Blocks source code.

Tim S.
58
The wxWidgets I used was the trunk version that was just updated today before building. ( last revision was 71bb680 )

and the mingw version I used was their installer:

https://mingw-w64.org/doku.php/download

Specifically:

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download

and yes the wxWidgets version I'm using seems to work fine with my software that I wrote.
59
Does this wxWidgets version work with an other compiler?
60
Just tried compiling on win 7 64bit with the 32 bit version of mingw. I have tried both versions of mingw 7.1 and mingw 8.1 and they both fail at the same place below:

Post link to at least one compiler installer that fails with build error.

Edit: Also, post the wxWidgets version information.

Tim S.
Pages: 1 2 3 4 5 [6] 7 8 9 10