🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Dev-cpp: Using the DLL compiled with VC
Author
Hey there
i got a "little funny" question here...
I compiled AngelScript as a DLL using MS-Visual Studio .net using the ANGELSCRIPT_EXPORT define
then, created a ".a" file from the ".lib" i for from VS using MinGW's tool: reimp
so that i could use that same DLL on Dev-CPP
fine?
yeah, fine, cool, nice and all...
the problem is:
cant run
i tryied compiling the "Concurrent" sample
and yes, it compiles; but, when i try to run, it simply hungs up X_X
talking about an unwanted error message saying "bla bla bla, microsoft sucks, bla bla bla, you program has crashed on AngelScript.dll"
when i use the DLL compiled with Dev-cpp, everything works just fine
even when i use the ".a" i got from VC's .lib
do i need a different DLL for every different compiler? :(
The code produced by different compilers for calling functions is different so, unless in some specific cases like only global cdecl functions that don't pass any object by values, they will be incompatible with each other. Even if the symbol names can be found by the linker.
Method pointers are also packed differently on different compilers, e.g. GNUC uses an 8 byte structure for all types of method pointers, whereas MSVC uses everything from 4 to 20 byte structures depending on the type of class.
That said, there is a way in which you should be able to get things working, and that is to use the C interface. The C interface is already successfully being used by other languages, such as Delphi, so it should work in your case as well.
To use the C interface you'll have to compile the library with the AS_C_INTERFACE defined.
Maybe you can get away with just AS_MAX_PORTABILITY, but I'm not sure the virtual methods of the library methods are compatible between compilers.
Regards,
Andreas
Method pointers are also packed differently on different compilers, e.g. GNUC uses an 8 byte structure for all types of method pointers, whereas MSVC uses everything from 4 to 20 byte structures depending on the type of class.
That said, there is a way in which you should be able to get things working, and that is to use the C interface. The C interface is already successfully being used by other languages, such as Delphi, so it should work in your case as well.
To use the C interface you'll have to compile the library with the AS_C_INTERFACE defined.
Maybe you can get away with just AS_MAX_PORTABILITY, but I'm not sure the virtual methods of the library methods are compatible between compilers.
Regards,
Andreas
Author
Quote: Original post by WitchLord
[...]
That said, there is a way in which you should be able to get things working, and that is to use the C interface. The C interface is already successfully being used by other languages, such as Delphi, so it should work in your case as well.
[...]
i was afraid of that T_T
oh well...
whatever if works...
*now testing...*
Hi, it is acually incredibly easy to take the source from the site and make dev-c++ compile the .a for you directly.
Just create a new Static Library project, remove its default main file, then add the ones in the source.
Finally compile, it will instantly create the .a file that you will be able to use by just including angelscript.h and adding the .a file as library
Just create a new Static Library project, remove its default main file, then add the ones in the source.
Finally compile, it will instantly create the .a file that you will be able to use by just including angelscript.h and adding the .a file as library
It's even easier than that, just use the project file already supplied with the SDK download. [wink]
However, I believe ALRAZ already knows that.
His problem is slightly more difficult than just compiling a library file, since he wants to have a DLL file exposing C++ interface that is compatible with different compilers. Unfortunately this is simply not possible, as different C++ compilers don't produce binary compatible code.
However, I don't know of any C++ compiler that is not able to produce ANSI C binary compatible code (i.e. global cdecl functions, that doesn't pass around C++ objects by value). So by restricting the interface of the DLL to ANSI C, any compiler should be able to use it.
I think I'll add this as a tip in the AngelScript manual.
However, I believe ALRAZ already knows that.
His problem is slightly more difficult than just compiling a library file, since he wants to have a DLL file exposing C++ interface that is compatible with different compilers. Unfortunately this is simply not possible, as different C++ compilers don't produce binary compatible code.
However, I don't know of any C++ compiler that is not able to produce ANSI C binary compatible code (i.e. global cdecl functions, that doesn't pass around C++ objects by value). So by restricting the interface of the DLL to ANSI C, any compiler should be able to use it.
I think I'll add this as a tip in the AngelScript manual.
Seems I didn't read correctly again, sorry
Edit: from what I can read, just use the libraries for the compiler you are using and it should all be fine, cause I think that you said that using the library compiled with Dev-c++ the concurrent sample works correctly?
In that case what's the reason to use the VC dll?
Edit: from what I can read, just use the libraries for the compiler you are using and it should all be fine, cause I think that you said that using the library compiled with Dev-c++ the concurrent sample works correctly?
In that case what's the reason to use the VC dll?
Author
Quote: Original post by Vexorian
Seems I didn't read correctly again, sorry
Edit: from what I can read, just use the libraries for the compiler you are using and it should all be fine, cause I think that you said that using the library compiled with Dev-c++ the concurrent sample works correctly?
In that case what's the reason to use the VC dll?
that's becouse i want people to be able to re-compile the App without worring about what compiler to use, and without having to recompile AngelScript.
having different DLLs would only cause a mess.
And including Angelscript as part of the app would make the .exe too big and take too much time to compile for many programmers out there
Well you could distribute it with a directory with different DLLs for each compiler, still a screw up.
I don't think that a static library would increase so much time, in fact it doesn't.
You can also just distribute it with angelscript's source. And there are always witchlord's solutions
I don't think that a static library would increase so much time, in fact it doesn't.
You can also just distribute it with angelscript's source. And there are always witchlord's solutions
Author
what am going to do is use GNU's compiler as standard
and problem solved -_-
still dont like it, but it saves a lot of time, problems, and so...
and, if someone wants to use a different compiler, they can still re-compile everything, since it is suposed to be open source
[Edited by - ALRAZ on October 23, 2005 1:30:59 PM]
and problem solved -_-
still dont like it, but it saves a lot of time, problems, and so...
and, if someone wants to use a different compiler, they can still re-compile everything, since it is suposed to be open source
[Edited by - ALRAZ on October 23, 2005 1:30:59 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
