Re: [Mingw-users] "brige user" - wxwindows with mingw

[Oscar F. <of...@wa...>]

Chirayu Krishnappa <roc...@gm...> writes:

> Hi everybody,
> 
> I'm a quite recent and silent member of this group. I recently
> (yesterday) upgraded all the mingw packages and tried compiling
> wxWindows 2.2.9. I needed to make the following changes to get a
> successful compile.
> 
> 1) use the -Wno-deprecated flag as they use the older headers (.h headers)

Well, this just a warning. It doesn't affect to the produced code.

> 2) fontenum.cpp: line 137: CALLBACK qualifier missing: change line from
> #define wxFONTENUMPROC int (*) (const LOGFONTA *, const TEXTMETRICA *,
> to
> #define wxFONTENUMPROC int (CALLBACK *) (const LOGFONTA *, const
> TEXTMETRICA *,

The right solution here is 

#define wxFONTENUMPROC FONTENUMPROC

if I remember correctly.

> 3) tbar95.cpp: line 1114, 1115: change the call from max(...) to std::max(...)

Yup.
 
> 4) thread.h: line 35:
> this line #includes module.h. just before this there is a test -
> #ifdef Yield, #undef Yield, #endif. module.h should be #included just
> before this and not just after this.
> 
> 5) common/dynlib.cpp: line 304: change from
> symbol = wxDllGetSymbol(dllHandle, name.mb_str());
> to
> symbol = (void *) wxDllGetSymbol(dllHandle, name.mb_str());

Are you using gcc 3.1? There are some issues converting pointer to
functions to void pointers with 3.1, as it seems.
 
> 6) msw/ole/uuid.cpp: line 32:
> #include <rpc.h> dosent seem to work correctly. a #include <windows.h>
> just before this line fixes the undefined symbol errors which would
> otherwise be generated. perhaps the rpc.h file needs to be fixed and
> not the wxwin sources here (rpc.h includes windows.h which includes
> rpc.h......maybe the source of the problem. can anyone help me here?)

When wxWindows includes <windows.h>, soon afterwards it #undefines a
lot of macros defined by windows.h, wxWindows depends on undefining
that symbols for a correct compilation. With gcc 3.1 some MinGW header
files now #include <windows.h> so for some units wxWindows sources
assumes that no <windows.h> was included still, when really it was
included by a MinGW header. Hence the macros affects wxWindows
code. The solution is to 

#include <winundef.h>

at certain strategical points. As now I'm using the CVS version of
wxWindows and wiped out 2.2.9, I can't remember where it was needed.
 
> All the above problems, except for (6) seem trivial and fixing them
> should hopefully not result in build errors for other platforms. The
> use of deprecated headers cannot be eliminated trivially (for example
> by changing #define wxUSE_IOSTREAMH to 0 in setup.h, line 601) since
> the "using namespace std" lines are not compiled for mingw..
> 
> I'm confused about one gcc flag -fvtable-thunks.

I don't know about this.

> I remember having read (a few years ago) that using this flag
> required ALL other libraries linked with to also have been compiled
> with the same flag (if they used virtual functions). wxwindows uses
> this flag (with mingw 1.1) however, linking with libstdc++ with and
> without this flag dont seem to make much difference. Perhaps I am
> not making any virtual function calls on libstdc++. Also, gcc 3.1
> warns this flag has no effect. wxwindows uses this flag and i'd like
> to know what the implications of this change are (in general).

This should be good to know, although I suspect that when the GCC
people deprecated the flag, it was because it really is no longer
needed, so no problem.

> Please help me if possible or direct me to the correct newsgroup. I am
> really sorry for posting this to the mingw users list but I have no
> idea where to post this.

Very recently the wxWindows developer (and user) mailing list talked
about this issues, although applicated to 2.3.x version.

This questions (except possibly for the -vtable-thunks) belongs to the
wxWindows mailing list.

> ps: I also seem to have some link problem (not finding funcitons in
> fontutil.o which I'm currently ovecomng by including the object file
> in the build.

Curious. Other that when building as a dll, I've not found any linking
problem with wxWindows. Maybe it's related with some change you did.

-- 
Oscar