missing symbols in dll created from LabVIEW

[keshavanbp]

I'm trying to create a DLL for the VI written in LabVIEW.

My purpose is to use this DLL in C or scripting platform.

When I check whether this dll contains the symbols using 'nm'; I find the message "no symbols".

However, when I use the dll in another labview file, I'm able to see the function-name.

Is there a way to create the dll, such that, it has the symbols that can be used in 'C' or other scripting environments?

[keshavanbp]

Is there anything special that I need to do - to be able to use DLL generated from LabVIEW or CVI in a 'C' application?

[mikeporter]

I'm not sure what you mean by using 'nm'. But there is nothing special that you need to do to make a DLL callable from C.

Mike...

[keshavanbp]

Thanks for the revert Mike.

"nm" is a utility. It helps in listing the symbols in a executable or shared-library (dll).

I found the following link - http://digital.ni.com/public.nsf/allkb/70995EC2CA1B523386256DD4004F3DE6

This only provides partial information that I'm looking for. It shows that  *.lib file contains the symbol information. Probably the dll has been stripped of the symbol information.

When I include the LabVIEW dll in a VI, I'm able to go and select the function name that I want the DLL to execute. I'm unable to do the equivalent of this when I include the same in my C-code.

[rolfk]

What prevents you from linking the LabVIEW created .lib file to your C program to provide you with the correct function stubs? I never really create LabVIEW DLLs but always do it the other way around by incorporating other DLLs into LabVIEW, so can't really tell you why the symbols don't show up. It could be that LabVIEW chooses to export them as ordinal only but that would be a bit strange. Have you tried to open that DLL in the depends.exe utility? That might show you if your GNU tool nm is to be blamed for not seeing anything.

Anyways another thought: Your use of nm seems to indicate that you are coming from the Unix world with the elf shared library format. Unlike with elf where you can simply reference symbols from a shared library in your executable code and let ldshared resolve the dependency at runtime, DLLs in Windows work differently. You either have to link your binary file with a so called import library which locates all the DLL entry points at load time of the executable or you have to explicitedly link to the symbols yourself by using the LoadLibrary(), GetProcAddress() and FreeLibrary() Windows APIs.

And you might be using a Gnu based C toolchain which might explain why you can't link the LabVIEW generated .lib import library. This library is using the Microsoft COFF format, not the ELF format that GCC is using by default. Only a few Microsoft specific GCC variants like MingW support COFF and other Microsoft specialisms at least to some extend.

[keshavanbp]

Thanks for the detailed explanation Rolf.

I'm working on it. Will revert after completing my experiment