Ney André de Mello Zunino wrote:
Cedric Gustin wrote:
Could you elaborate on the reasons why your communication library requires Visual C++ ? Is it a C or C++ library ? What are its requirements (MFC...) ?
I may have been misleading by saying "building object files for each library". When I say 'build' here, I actually mean building an application which uses a given library, as opposed to building the library itself. So, the scenario I have is an application which simultaneously uses facilities from the communications library and GTKmm. As of now, I use MSVC's tools to build applications which use the former and Cygwin/g++ for those which use the latter.
I see. The problem is incompatible C+ name mangling schemes between MSVC and gcc. More precisely..
1. If your communication library in written in C, try to use mingw32-g++ for your application, link against my gtkmm for mingw32 binaries. Then either try to directly link against your MSVC-generated DLL (using the g++ auto-import feature) or against a mingw32 import library that can be created from the original DLL using pexports (http://starship.python.net/crew/kernr/mingw32/Notes.html)
Alternatively, you can follow the guidelines of the mingw32 FAQ (http://www.mingw.org/mingwfaq.shtml#faq-msvcdll)
2. If your communication library in written in C++, you have to use a single compiler suite for all libraries and executables. Either you rebuild your communication library with mingw32-g++, or you try to use my gtkmm-2.4 binaries for Visual Studio.Net 2003, which are working OK except this nasty "this pointer in constructor of virtual base class" compiler bug.
Cedric
Attachment:
signature.asc
Description: OpenPGP digital signature