LabVIEW
Using mingw to make a .dll for use in labview ?
I have seen some posts on this, but none of them take it all the way from C code to configuring the shared library node...
My code is heavily based on this:
http://forums.ni.com/ni/board/message?board.id=170&thread.id=171056
Here are my files:
//reedll.h
#ifdef BUILD_DLL
// the dll exports
#define EXPORT __declspec(dllexport)
#else
// the exe imports
#define EXPORT __declspec(dllimport)
#endif
// function to be imported/exported
EXPORT void tstfunc(int A, int B, int C);
and:
//DLL_Test.c
#include "reedll.h"
EXPORT void tstfunc(int A, int B, int C)
{
C = A + B;
}
Its meant to be as bare bones as I can get it. No crazy pointers or anything.
I compile as follows usin MinGW:
g++ -c -DBUILD_DLL DLL_Test.c
g++ -shared -o tst.dll -Wl,--out-implib,libtstdll.a DLL_Test.o
And it appears to compile fine.
When I go to import the .dll into the shared library node the "Function Name" field is garbled and says "Z7tstfunciii" instead of "tstfunc". Needless to say the shared library function icon that results doesnt work
You should tell the mingw compiler to not name mangle the symbols. Most likely you use a cpp file enxtension and then mingw as Visual C will invoke the cpp compiler instead of c which by default name mangles function names.
If you want or need to use cpp, you can also try to declare your exported symbols like this:
#ifdef __cplusplus
extern "C" {
#endif
EXPORT void tstfunc(int A, int B, int C);
/* all the other function prototypes you do not want to be mangled */
#ifdef __cplusplus
}
#endif
Not sure if __cplusplus is defined by mingw, if not you have to find how it indicates that C++ mode has been invoked.
You describe in detail what you have done and checked -> very good.
But you don't mention at all what does not work. What does not work? Do you get error messages and where? Do you use error handling? Have you tried to debug it in LabVIEW and/or C? What LabVIEW version? You created a 64-bit DLL but are you also using 64-bit LabVIEW for this?
Can you compile a mini test program in MingW that attempts to load this DLL with LoadLibrary() and GetProcAddress()? Do you have access to Visual C to compile this mini test program. It may work in the mingw executable but not in an executable created with anything else than mingw because it can not reference the mingw version of the Gnu C runtime library (it may not be properly installed on your computer). When you load the program in the mingw test executable the executable itself already loaded that library and the DLL may just link to it, but by non mingw application that does of course not work. Generally it is a mingw problem that you should try to resolve in the mingw community. Almost nobody who uses LabVIEW is likely to use mingw and even less so know anything useful about mingw.
Once you manage to load the DLL in another non-mingw application, be it Visual C or whatever, we can debug further with eventual LabVIEW problems, but I'm pretty sure that they will be gone too then. If the mingw community can't or doesn't want to support this use case at all, they could just as well remove the ability to create a DLL. It is basically useless to be able to create DLLs that can only get loaded by executables created by the same compiler.
It probably does have other dependencies namely at least the MinGW threading support library unless you compile the DLL for single threaded use.
You installed MingW however it might not have installed this necessary runtime libraries in a way that can be easily found by non MingW executables, which LabVIEW is not one.
It looks like an improvement but be aware of one thing: Just because it does not crash anymore, does never mean that everything is right. You can have horrible configuration errors in the Call Library Node or outright memory bugs, and everything seems to be fine. That is until you change something seemingly unrelated and suddenly your machine crashes all the time.
Memory buffer overflow errors and other related bugs are a nasty breed to avoid. They can crash your program good, or they can hide for some time to hit you right in the final stage of your project. Even if they hide they do corrupt memory somehow somewhere, just not in a way that is fatal for your program. Instead you could end up having illogical results in other areas of your program. Basically if they destroy memory that is used as pure data somewhere else, wrong results could result, if they corrupt memory that is used/translated at some point to memory addresses, things get usually more frappant with real crashes and exceptions.
And as far as __stdcall is concerned. You need of course to make sure to configure the Call Library Node accordingly. Just look in the original post in the picture where you can configure the calling convention for a function in the Call Library Node.
Most C compilers including Visual C default to __cdecl calling convention when nothing is specified. This can be overwritten in Visual C in the project settings (and with GCC based compilers with a command line option) but the caller has to use the same calling convention of course than what was used for compiling the function.
Accordingly when you create a test program to test the DLL loading with GetProcAddress() the function pointer has to be declared with the right calling convention too, or things go immediately into chaos as soon as your code comes to the point to try to call this pointer.
__stdcall and __cdecl are not decorations to a function declaration, they are essential and influence what code the C compiler will create to put the parameters on the stack and how they will be removed from the stack after the function returns. If the caller and callee don't agree on the same convention, immediate stack corruption is unavoidable and that causes a very quick process termination.
