Cygwin DLL with Labview

[PipT]

I am trying to use a DLL generated by Cygwin (using gcc) in a Labview
Call Library Function node. I'm using Labview 8.2.

I started with a trivial example: a couple of functions that just
add or multiply two input values. I can generate what appears to
be a valid DLL using Cygwin. Labview recognises its functions, using
the Import Shared LIbrary wizard or Call Library Function configure.

But it would always fail as it couldn't locate cygwin1.dll which
is referenced by all cygwin generated code.

So I added the location of cygwin1.dll (C:\cygwin\bin) to my Windows
PATH environment variable. Now Labview just hangs/crashes whenever I
try to use my DLL in Labview. I have to kill Labview using Task
Manager or even reboot.

If I remove the ";C:\cygwin\bin" element from %PATH%, the hang
problem goes away (but of course I still have
the missing cygwin1.dll problem again)

See also the Oct 26 2004 post
"Using a cygwin DLL in LabVIEW 7.0"
which looks like virtually the same (unresolved) problem

Philip

[Kurt_NISalesEngineer]

Hi

Thanks for posting your query on the national instruments forums. I'm wondering what the calling convention for the DLL is. LabVIEW supports WINAPI and C calling conventions only.

Can you post the DLL on the forums as an attachment for us to look into the issue a little further? Please also provide any documentation / header files that come with the DLL file.

Thanks

Kind Regards,

Kirtesh Mistry

Applications Engineer

National Instruments UK & Ireland.

[Bob_Y.]

This probably has nothing to do with it, but is cygwin1.dll registered?  If it isn't you could try to register it and see if that helps.  (Start -> Run -> "regsvr32 cygwin1.dll").

Hope that this helps,
Bob Young

[nmi]

Same error message in LabVIEW 2015. Is there a solution?

[rolfk]

Your post is very unclear. The original poster had two problems.

1) Windows could not locate the dependency for the Cygwin runtime DLL. This is totally independent of LabVIEW. An application never knows about secondary dependencies of DLLs. Windows is supposed to resolve them but because of the rather non-standard installation location for the Cygwin runtime environment, it can't. This error causes an error message that LabVIEW could not load your DLL, since when LabVIEW told Windows to load it, Windows failed to load it as it could not find the Cygwin runtime DLL. Windows simply tells LabVIEW: sorry could not load the DLL but not a detailed cause why. 

2) If you add the directory with the Cygwin runtime library to the PATH environment variable, then Windows can find the Cygwin runtime DLL but on the OPs computer this hangs the entire LabVIEW system. Note that in that case there is no error message, so I assume you didn't even try to modify the PATH environment variable?

I haven't used Cygwin so far and don't know what the Cygwin recommended way is to distribute DLLs created with Cygwin for use with other computers, but it is almost certainly NOT to add the standard Cygwin installation directory to the PATH environment variable, although Cygwin being for a large part more Unix than Windows, it might be possible that they chose that. More likely you are probably supposed to distribute the Cygwin runtime support DLL with your application.

Read this thread about using Cygwin generated DLLs without installing Cygwin on the target computer.

Basically the message about Cygwin1.dll behaving rather badly if it is loaded multiple times on the same computer might be the original reason for the hang.

From that thread the recommendations would be in order of preference:

1) Compile your DLL with the -mno-cygwin flag in Cygwin to avoid the whole Cygwin runtime inclusion. This will however fail if your DLL makes Posix calls.

2) Try to use MSYS and MinGW instead to compile your DLL. This will result in a more Windows like DLL.

3) Install Cygwin1.dll into Windows\System32 directory (and avoid that it is present anywhere else on your computer)

In conclusion the whole difficulty has most likely nothing to do with LabVIEW itself, but rather with the somewhat non-Windows like architecture of Cygwin, which doesn't quite work as other Windows components.