User forums > General (but related to Code::Blocks)

Workaround to compile wxWidgets 2.6.3 with GCC 4.1.0 (MinGW)

(1/2) > >>

Michael:
Hello,

Until now, I and other wxWidgets's users could not build wxWidgets 2.6.3 with GCC 4.1.0 on Windows (MinGW). Some minutes ago, I got an interesting e-mail from wx-users@lists.wxwidgets.org with a possible workaround :D. I think it could be interesting for some users:


--- Quote ---[...]
I also encountered this issue using my CygWin-hosted, MinGW-targetting build of the latest GCC 4.1 snapshot, when trying to build wxWidgets from CVS HEAD.

A little investigation revealed that, for some reason, the culprits are the implementations of virtual functions AddRef and Release, present in several of the interfaces used in src/msw/ole/activex.cpp.

Since I currently have no use for the ActiveX technology, my private workaround is to comment out (until a proper solution is found) the bodies of those two functions, like this:

Index: src/msw/ole/activex.cpp
===================================================================
RCS file: /pack/cvsroots/wxwidgets/wxWidgets/src/msw/ole/activex.cpp,v
retrieving revision 1.21
diff --unified -r1.21 activex.cpp
--- src/msw/ole/activex.cpp     2006/03/23 10:11:05     1.21
+++ src/msw/ole/activex.cpp     2006/04/04 17:43:56
@@ -79,7 +79,7 @@
          ((IUnknown * )(*ppvObject))->AddRef();\
          return S_OK;\
      }\
-    ULONG STDMETHODCALLTYPE cls::AddRef()\
+    /*ULONG STDMETHODCALLTYPE cls::AddRef()\
      {\
          InterlockedIncrement(&refCount.l);\
          return refCount.l;\
@@ -98,7 +98,7 @@
          }\
          else\
              return 0;\
-    }\
+    }*/\
      ULONG STDMETHODCALLTYPE cls::AddLock()\
      {\
          InterlockedIncrement(&lockCount.l);\

This allows for the rest of the library files to compile.

Best regards.

--
Wlodek Szafran

--- End quote ---

Best wishes,
Michael

Michael:
Hello,

After trying the workaround, I have discovered that it does not work as I wanted :(. The problem is that it works, but to compile wxWidgets 2.6.3 and not to build it. Commenting out the implementation of two functions in the activex.cpp file make the linker throws undefined reference exceptions :(.

I have tried some alternatives, but all failed. May be if C::B does make use of non-monolithic version, it could be possible (at list in theory) to just skip the activex stuff.

Moreoever, after some investigation, the author posted this message:


--- Quote ---I've done some more digging and it turns out that this problem has nothing to do with ActiveX/COM or MinGW directly.  It seems that in a multiple inheritance situation, when the virtual functions have the attribute __stdcall__ applied, the compiler is improperly generating the vtable.   I've put together a small program which doesn't know anything about wxWidgets or ActiveX or Win API, in which I can reproduce this erroneous behaviour.  One of these days, time permitting, I'm going to submit a problem report to the GCC developers.

--- End quote ---

The problem seems related to the compiler and not to ActiveX/COM or MinGW (not directly at least). If there was just a solution to get rid of activex...

Sorry for the false hope :oops:. I will correct the title from "to build" into "to compile".

Best wishes,
Michael

David Perfors:
Did you try it with the patch? http://wxwidgets.org/patch.htm#patches263

Michael:

--- Quote from: mispunt on April 07, 2006, 09:43:24 am ---Did you try it with the patch? http://wxwidgets.org/patch.htm#patches263

--- End quote ---

Yes. I have tried even with the latest CVS wxWidgets. The problem seems to be compiler-specific. I just wonder if a cross-compiling in Linux could work...

Best wishes,
Michael

Tactive:
Hello,

I would like to know where you got the GCC 4.1.0 from? Actually candidate for GCC of the MinGW project is 3.4.x as I can see on the homepage. Did you compile GCC yourself?

- Tactive

Navigation

[0] Message Index

[#] Next page