From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

DLLImport variable and library Linking question

Hello All,

 

I am using a CVI program with an external DLL file.

My program is designed to be able to load a specific DLL file from a collection  of possible files depending on the required task.

I am making a common variable "result" in each DLL fille.

 

In my CVI program it is defined as int DLLIMPORT result;

In my DLL I have the variable defined as int DLLEXPORT result;

 

When I use the DLLIMPORT function for my program to get the variable "result" from the DLL, I get error:Undefined symbol "_imp...

 

If I include the library for one of my DLL's in my CVI program, this error goes away, of coures.

But because I am using multiple DLL's, one at a time, I do not want to link any librarys to a specific DLL.

 

I haven't had any issues using my DLL's with DLLEXPORT, but DLLIMPORT is giving me this linking issue when I build it.

 

What can I do to define my DLLIMPORT variable so I can bypass linking a library to my CVI program?

Veni Vidi Duci
0 Kudos
Message 1 of 5
(4,983 Views)

Hey DQ_IQ,

 

Are you trying to link these DLLs statically? If so, then you'll have to include the library file. The alternative, of course, would be to load the DLLs dynamically, which does not require the library files. The benefit here is that you could load the DLL at run-time based on which one you need rather than having to include all of the library files, like you mentioned. Take a look at the article linked below about implementing dynamic linking.

 

Calling a DLL in CVI: Explicit Linking vs. Implicit Linking (Dynamic vs. Static):

http://www.ni.com/white-paper/8503/en/

 

Regards,

 

Ryan

Ryan P.
CLA
0 Kudos
Message 2 of 5
(4,945 Views)

Hello, thanks for the reply.

 

I am using explicit linking, and currently it works very welll for executing functions in the DLL.

I am doing exactly what the example shows, with a typedef and function call to a DLLEXPORT function defined in my DLL.

 

The problem is if I execute a DLL funciton, and save two or more variables that I cannot use as a return, I would like to use DLLIMPORT to bring variables into my CVI program FROM my DLL file.

The library has the definitions for the DLLIMPORT variables, but again I can't link to the library in this case.

 

How do I explicitly define DLLIMPORT variables for dynamic linking?

 

Thanks again.

Veni Vidi Duci
0 Kudos
Message 3 of 5
(4,940 Views)

You aren't defining the result variable in more than one location, such as a header file of some sort, correct? This could possibly cause the variable to link to another instance of the DLL. Also, is the result variable defined as a global in your DLL?

 

One thing you could try is to just make accessor functions for the result variable. That way you wouldn't need to worry about using DLLIMPORT since functions don't require that identifier. Then you can just call that accessor function to retrieve the current value of result.

Ryan P.
CLA
0 Kudos
Message 4 of 5
(4,903 Views)

I defined a DLLEXPORT variable inside the DLL header file.

 

In my main program, I have a DLLIMPORT statement in my global header file for my main declaration, and then a EXTERN DLLIMPORT for any additional files in my program.

 

Basically I have multiple c files

In my main.c file I define MAIN.

In all my C files I include a global.h

 

Inside global.h I have:

#ifdef MAIN

DLLIMPORT variable;

#else

EXTERN DLLIMPORT variable;

#endif

 

That's what I was doing. I changed my desgin though.

 

I moved away from using DLLIMPORT in my program.

I am now passing a pointer to a structure everytime I call my DLL functions using DLLEXPORT, similar to the sample above.

Then my DLL can save data to memory in my main program using that pointer.

As long as my DLL's use consitent formatting (which is the idea), this should be adequate.

I have tested this and so far it works pretty well.

Veni Vidi Duci
0 Kudos
Message 5 of 5
(4,884 Views)