create a dll for windows with gcc

vincent72 · ‎03-02-2006

hello!

I have made a program in 'C' under linux and i want to make it into a dll with gcc to use it in labview under windows.

Has anyone already done a such thing? so what is the magic option to pass to gcc to make it properly?

Thank you.

rolfk · ‎03-03-2006

@vincent72 wrote:
hello!

I have made a program in 'C' under linux and i want to make it into a dll with gcc to use it in labview under windows.

Has anyone already done a such thing? so what is the magic option to pass to gcc to make it properly?

Thank you.

There is a little more necessary than just a compiler to build proper executables. You need a complete toolchain, which also includes appropriate runtime library support for your target OS as well.
I haven't tried this yet, but your best bet would be to try MingW http://www.mingw.org/ that uses gcc as compiler but also provides the entire toolchain for Win32 application development. I would expect this to be some hassle before everything is setup corerctly to allow to create proper Win32 applications, and maybe even some more tweaks to get a MingW DLL to properly work with LabVIEW.

If you prefer graphical IDEs you could try Dev C++ from http://www.bloodshed.net/ that builds on MingW but provides a modern graphical IDE user interface.

Rolf Kalbermatter

Rolf Kalbermatter
My Blog

JMA_eng · ‎03-03-2006

Greetings,
I have not used MinGW for dll construction, but you should be able to create a dll. Listed below is a small example from the MinGW documentation.

Justin

How to create a dll

Here's an example. Cut and paste the following into a file named dllfct.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 (void);

Cut and paste the following into a file named dllfct.c:

   #include <stdio.h>
   #include "dllfct.h"

   EXPORT void tstfunc (void)
   {
      printf ("Hello\n");
   }

Cut and paste the following into a file named hello.c:

   #include "dllfct.h"

   int main ()
   {
      tstfunc ();
      return (0);
   }

To create the dll and an executable that uses it, try the following:

   gcc -c hello.c
   gcc -c -DBUILD_DLL dllfct.c
   gcc -shared -o tst.dll -Wl,--out-implib,libtstdll.a dllfct.o
   gcc -o hello.exe hello.o -L./ -ltstdll

vincent72 · ‎03-07-2006

Thank you for your replies.

unfortunately, these options don't work on our computer.

the keyword 'declspec' wasn't reconnised by our gcc.

we also tried the keyword '__attribute ((dllexport))__' but it didn't work anymore.

regards.

vincent.

rolfk · ‎03-07-2006

@vincent72 wrote:
Thank you for your replies.

unfortunately, these options don't work on our computer.

the keyword 'declspec' wasn't reconnised by our gcc.

we also tried the keyword '__attribute ((dllexport))__' but it didn't work anymore.

I think the standard gcc attribute is more something like attribute(export). After all gcc environments typically use shared libraries and not DLLs. But then again not every gcc compiler will be able to just create proper Win32 executables. As explained already, there needs to be quite a lot in the toolchain for the intended target.
For instance the compiler/linker should support COFF library format in order to create a valid Win32 executable file unless you have a your own format specific Win32 compatible loader that gets linked in and understands your library format. Also declspec() is a Microsoft specific extension not supported by off the shelf gcc. And gcc has no intentions to add anything they consider non-standard, and most Microsoft extensions are non-standard.

MingW does come with a patched gcc, that supports the most important things to be able to create valid Win32 executables but most other gcc versions don't.

Rolf Kalbermatter

Rolf Kalbermatter
My Blog

abraker · ‎02-08-2018

This is definitely possible. It would be easier to figure out if Labview gave better error messages when the function doesn't load right.

I was able to compile the following example into a dll and use it in the Labview Call Library Function Node;

aMultb.c:

#include "aMultb.h"
int aMultb(int a, int b){
  int c = a*b;
  return c;
}

aMultb.h:

extern "C" {
  __declspec(dllexport)  int aMultb( int a, int b );
}

I compiled this with the 32 bit version of msys2. I think you can also use the 64bit version if you specify a different compiler. To compile, I ran:

g++ -static-libgcc -c aMultb.c
g++ -static-libgcc -shared  -o aMultb.dll aMultb.o

The flag -static-libgcc keeps labview from complaiing about libgcc_s_dw2-1.dll.

Hope this helps somebody.

rolfk · ‎02-08-2018

wrote:

This is definitely possible. It would be easier to figure out if Labview gave better error messages when the function doesn't load right.

LabVIEW uses the Windows API LoadLibrary() to try to load a DLL into memory. LoadLibrary() is pretty terse in terms of error handling. It either succeeds or it doesn't and it does not really return much more detailed information about the reason for the failure. GetLastError() can be called to get some more information but the returned error codes are not really documented and vary between different Windows versions, so it is a bit tricky to use that for more than some very basic error indication.

In order to give more meaningful error messages about failed dependencies LabVIEW would need to implement its own dummy PE file parser to try to determine all dependencies, then try to locate them to search rules that can vary between Windows versions and depending on the security restrictions imposed in the current Windows session by an IT departement or similar.

I hope that you can see that this is a pretty useless and resource spilling exercise.

I was able to compile the following example into a dll and use it in the Labview Call Library Function Node;

aMultb.c:
#include "aMultb.h"
int aMultb(int a, int b){
  int c = a*b;
  return c;
}
aMultb.h:
extern "C" {
  __declspec(dllexport)  int aMultb( int a, int b );
}
I compiled this with the 32 bit version of msys2. I think you can also use the 64bit version if you specify a different compiler. To compile, I ran:
g++ -static-libgcc -c aMultb.c
g++ -static-libgcc -shared  -o aMultb.dll aMultb.o
The flag -static-libgcc keeps labview from complaiing about libgcc_s_dw2-1.dll.

Hope this helps somebody.

My last post is now 12 years old. That is an almost infinite time period in computer terms. The state of affairs with GCC has certainly changed in that time and the latest versions of GCC support many Microsoftismes although it can be taunting to find the right command line option to pass to GCC to enable such a feature.

Still, compiling the code is one first step. Linking it to a final executable is an entirely different one and eventhough GCC also supports many different flavors and targets nowadays you usually need additional support in terms of target specific linker scripts. Specific GCC distributions like MSys or MingW come with the correct support scripts that massage the command line options into a form to get the GCC compiler and linker to emit the correct formats.

And if you get the libgcc_s_dw2-1.dll installed on your Windows system I see no reason why a DLL compiled to depend on this runtime library would not be able to load in LabVIEW.

Rolf Kalbermatter
My Blog

abraker · ‎02-08-2018

LabVIEW uses the Windows API LoadLibrary() to try to load a DLL into memory. LoadLibrary() is pretty terse in terms of error handling. It either succeeds or it doesn't and it does not really return much more detailed information about the reason for the failure. GetLastError() can be called to get some more information but the returned error codes are not really documented and vary between different Windows versions, so it is a bit tricky to use that for more than some very basic error indication

An obscure, poorly documented error code would be preferable, in my opinion, to none at all.

My last post is now 12 years old. That is an almost infinite time period in computer terms. The state of affairs with GCC has certainly changed in that time and the latest versions of GCC support many Microsoftismes although it can be taunting to find the right command line option to pass to GCC to enable such a feature.
Still, compiling the code is one first step. Linking it to a final executable is an entirely different one and eventhough GCC also supports many different flavors and targets nowadays you usually need additional support in terms of target specific linker scripts. Specific GCC distributions like MSys or MingW come with the correct support scripts that massage the command line options into a form to get the GCC compiler and linker to emit the correct formats.

And if you get the libgcc_s_dw2-1.dll installed on your Windows system I see no reason why a DLL compiled to depend on this runtime library would not be able to load in LabVIEW.

I replied to this post, even though it is 12 years, because it is still the first hit (for me at least) on google.

The point wasn't to say "I can compile this trivial function with gcc on windows". What I posted were the steps I used to compile and link the function into a dll that I could (and did) successfully use with labview's Call Library Function Node.

rolfk · ‎02-09-2018

An obscure, poorly documented error code would be preferable, in my opinion, to none at all.

I'm not sure I agree here. If you type in "LoadLibrary error code" on Google you end up with a a dozen or more recommendations for specific error codes, each of them gives you a few ten thousand or more hits with often very obscure and even totally wrong solutions, including the many fake sites trying to smear you with their DLL problem solver application that then reports you a whole bunch of problems on your computer that they are happy to solve for you when you download their paid for "real" application that in the best case does nothing except showing you a cleaned state of your machine after a long period of supposedly cleaning your machine and in the not so best case contains some other payload in the form of a virus, adware, troyan or some other shenanigan.

The other often seen solution is to grab some DLL from some often not very trustful download site and copy it somewhere on your machine. In my not so uninformed professional opinion, this recommendation is even worse than a failed load. In most cases it won't help since the person doing it has no idea what they are doing, and exposes the system to vulnerabilities due to wrong versions of DLLs or even intentionally altered DLLs with malicious content.

LabVIEW is not the environment to debug DLL dependency issues and other problems with DLLs. It is fully valid to assume that when you want to use a DLL in LabVIEW, that this DLL has been fully debugged already and it is properly installed on the system. Properly installing is not copying it somewhere on your machine and expecting it to work, but installing the DLL and ALL its dependencies according to the rules Windows imposes on DLLs. If you developed the DLL, you are responsible for debugging the DLL and creating such an installer and testing the installer on various machines with your own test applications and tools like the DLL dependency walker and Sysinternal's Process Explorer.

If you didn't develop the DLL yourself the original developer should have created such an installer and if he didn't, it is not LabVIEW's fault when that DLL can't be loaded. LoadLibrary() failed and the state of affairs around this function is that the retuned error code varies wildly between Windows versions including giving sometimes even misleading hints.

Microsoft hasn't for no reasons removed any mentioning of specific error codes from the MSDN page for this function!

The current documentation states:

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

and then leaves everything else to the programmer to guess, second-guess and find a way in the long list of error codes.

If loading of a DLL fails in the LabVIEW Call Library Node, the DLL is broken, or it or one of its dependencies is not properly installed on the machine! There isn't much more LabVIEW can tell you at this point, then that Windows refused to load the DLL.

Rolf Kalbermatter
My Blog

abraker · ‎02-09-2018

wrote:

An obscure, poorly documented error code would be preferable, in my opinion, to none at all.

I'm not sure I agree here. If you type in "LoadLibrary error code" on Google you end up with a a dozen or more recommendations for specific error codes, each of them gives you a few ten thousand or more hits with often very obscure and even totally wrong solutions, including the many fake sites trying to smear you with their DLL problem solver application that then reports you a whole bunch of problems on your computer that they are happy to solve for you when you download their paid for "real" application that in the best case does nothing except showing you a cleaned state of your machine after a long period of supposedly cleaning your machine and in the not so best case contains some other payload in the form of a virus, adware, troyan or some other shenanigan.

The other often seen solution is to grab some DLL from some often not very trustful download site and copy it somewhere on your machine. In my not so uninformed professional opinion, this recommendation is even worse than a failed load. In most cases it won't help since the person doing it has no idea what they are doing, and exposes the system to vulnerabilities due to wrong versions of DLLs or even intentionally altered DLLs with malicious content.

So the reason Labview doesn't report the available error code is to prevent me from downloading malicious software? You can't seriously expect me to believe this.

LabVIEW is not the environment to debug DLL dependency issues and other problems with DLLs. It is fully valid to assume that when you want to use a DLL in LabVIEW, that this DLL has been fully debugged already and it is properly installed on the system. Properly installing is not copying it somewhere on your machine and expecting it to work, but installing the DLL and ALL its dependencies according to the rules Windows imposes on DLLs. If you developed the DLL, you are responsible for debugging the DLL and creating such an installer and testing the installer on various machines with your own test applications and tools like the DLL dependency walker and Sysinternal's Process Explorer.

This is precisely what the LabView documentation example suggests: creating and compiling a simple dll example in some random folder on your computer. There is no fancy "installer" involved. So either you are wrong, or NI is promoting poor development practices.

If loading of a DLL fails in the LabVIEW Call Library Node, the DLL is broken, or it or one of its dependencies is not properly installed on the machine!

This can't be entirely true, because I can create a program which has no problem calling the dll which labview fails to load.

This thread has become unproductive. I'm done.

LabVIEW