Author Topic: CB dll project -> used in an M$ Visual project : troubles  (Read 6802 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
CB dll project -> used in an M$ Visual project : troubles
« on: February 09, 2006, 04:42:01 pm »
Hello all,
I am in big trouble. I have created a dll project with CB. This created a main.c, I changed that into a main.cpp, since I will need some classes also. The exported function thoug are extern C, so no name mangling. I wrote a litlle test project (console app from CB), which uses the dll (loaded thourh LoadLibrary, and then GetProcAddress) --> all woks well.
But when a project from M$ Developer Studio (mfc app and regular code, that regular uses the dll), thinsk go wrong. The exported functions seem to work well. One of those exported functions is a factory function which return a pointer to an class object created on the heap in the dll. When invoking member methods on that pointer, things go wrong. Crash !! I tried several methods (some with arguments, others without, I had one with no arguments -> error box is complaining about priviliged instruction).

What surprises me is that antoher mingw project can use the dll, while an M$ project can't.

Help help help help .....
Lieven

anarxia

  • Guest
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #1 on: February 09, 2006, 05:10:59 pm »
You can't mix n' match C++ code compiled with different compilers, period. Name mangling is the least of your problems.
Use C if you want to support multiple compilers with the same DLL.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #2 on: February 09, 2006, 05:20:51 pm »
is it really that bad ??
If I get a third party dll for example, I don't know how it was build, nor if it's c or c++. So no guarantee on usability.
 :shock: :shock: :shock: Is it really that bad ?

Offline AkiraDev

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #3 on: February 09, 2006, 05:26:10 pm »
is it really that bad ??
If I get a third party dll for example, I don't know how it was build, nor if it's c or c++. So no guarantee on usability.
 :shock: :shock: :shock: Is it really that bad ?

While it's true that DLL's are really not compatible, you can still find a way to link MinGW DLLs to Microsoft compiled binaries. Have a look at MinGW.org, there are tools (like reimp) that allow you to this, and they explain how to do it.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #4 on: February 09, 2006, 06:09:12 pm »
While it's true that DLL's are really not compatible, you can still find a way to link MinGW DLLs to Microsoft compiled binaries. Have a look at MinGW.org, there are tools (like reimp) that allow you to this, and they explain how to do it.

Well, things are not so simple. DLL are not so compiler compatible, but there is also the problem of the imported library. Let me cite from libxml2 readme:

Quote
If you configure libxml2 to include iconv support, you will obviously need to obtain the iconv library and include files. To get them, just follow the links at http://www.gnu.org/software/libiconv/ - there are pre-compiled Win32 versions available, but note that these where built with MSVC. Hence the supplied import library is in COFF format rather than OMF format. You can convert this library by using Borland's COFF2OMF utility, or use IMPLIB to build a new import library from the DLL. Alternatively, it is possible to obtain the iconv source, and build the DLL using the Borland compiler.

In my specific case, I could compile libxml2, but not link it, because of libiconv. As I had the libs and the dll from compiled for windows (MSVC), I have tried as suggested above. Before with COFF2OMF, then with IMPLIB and finally with reimp. Well, nothing to do. May be I am doing something wrong, that's possible, but after 4 hours of trying and testing.... :roll:
 
May be the dll alone will work, but as I have to develop, I need an import library that would work with MinGW... :(

Michael

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #5 on: February 09, 2006, 10:03:01 pm »
In the code situation I am in now, I don't use an implib, I LoadLibrary and GetProcAddress. And I can call the exported functions. My trouble starts when the factory function (one of the exported functions) return a class object (well actually a pointer to a class object). Could it be, it's only c++ that gives troubles (every compiler probably does the name mangling different) ?

Tomorrow I am going to do one more experiment : I will translate my class to a simple struct and have all of it methods become a simple function, taking as a first argument a pointer to the struct (explicit this pointer mechanism). I hope this works ...

All other suggestions are off course welcome.


Offline pjk

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #6 on: February 10, 2006, 04:08:31 am »
Quote
The exported functions seem to work well. One of those exported functions is a factory function which return a pointer to an class object created on the heap in the dll. When invoking member methods on that pointer, things go wrong.
The exported function is not name mangled but the member methods of an object certainly will be and Microsoft and GCC are certainly  incompatible at this level. I am not a compiler guru but I believe the term is Application Binary Interface It not only involves name mangling but other compiler specifics such as structure alignment on word boundaries etc. This may not even be compatible across different versions of GCC. The GCC site has some information and links to more.  http://gcc.gnu.org/onlinedocs/libstdc++/abi.html
« Last Edit: February 10, 2006, 04:29:39 am by pjk »

Offline pjk

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #7 on: February 10, 2006, 04:14:20 am »
Sorry. I should add that there should little problem using DLL which export only C functions from one compiler to another. There is sometimes a problem with slight name modifications such as prepended underscores, but this is easily overcome with .def files.
The problem in killerbot example is that he has exported a C funcion but then used this function to export a pointer to a C++ object.
If you need to write your dll using C++, you can still make it usable by other compilers if you provide C functions which interface with the C++ objects such that the C++ objects are not seen outside the dll.
I not sure that this was expressed verywell despite english being my native language, but I hope you get my meaning.
« Last Edit: February 10, 2006, 04:25:57 am by pjk »

The Unlord

  • Guest
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #8 on: February 10, 2006, 09:54:36 am »
Hmm, I find all this quite hard to believe...  :shock:

How does, for instance, DirectX (or DirectShow) solve this (or other COM based API's).
What you do is call
CoCreateInstance(ClsID, blabla, &pObj);
which returns you a pointer to a COM object, on which you might for instance call
pObj->QueryInterface(blabla);
This, in the end is exactly the same, or am I missing smthg here?

This would mean that you can only develop DirectX apps with Visual Studio, or, more generally, COM apps with the compiler that generated the COM object you wish to use.
Hard to believe, but still...
« Last Edit: February 10, 2006, 10:31:51 am by The Unlord »

Offline pjk

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #9 on: February 10, 2006, 12:10:39 pm »
As I said I'm no guru and I know nothing of COM. I searched the mingw site for help and found the following from John Gaughan
Quote
COM is, at its core, a way to implement certain object-oriented
 functionality in non-object-oriented code As such it is inherently
 C-based, although it does work fine with C++
http://sourceforge.net/mailarchive/message.php?msg_id=9076353This may explain how it is possible to interface with com.

The Unlord

  • Guest
Re: CB dll project -> used in an M$ Visual project : troubles
« Reply #10 on: February 10, 2006, 12:23:48 pm »
I found this article, which basically says that it can be done, but with some things to take into consideration (like not using STL in your interface)
http://aegisknight.org/cppinterface.html