Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Linker error VC 2008

Solved!
Go to solution

I recently upgraded from Visual C++ 6.0 to Visual Studio 2008. I also upgraded to the most recent set of 488 libraries.

 

My code includes the following header file: C:\Program Files\National Instruments\Shared\ExternalCompilerSupport\C\include\ni4882.h

 

And my application, is linked with the following object file: C:\Program Files\National Instruments\Shared\ExternalCompilerSupport\C\lib32\msvc\ni4882.obj

 

When I compile, I get the following errors:

 

Error LNK2019: unresolved external symbol __imp__rand referenced in function _LoadFunction@4 ni4882.obj ctlcom


Error LNK2019: unresolved external symbol __imp__srand referenced in function _LoadFunction@4 ni4882.obj ctlcom


Error LNK2019: unresolved external symbol __imp__time referenced in function _LoadFunction@4 ni4882.obj ctlcom

Can anyone tell me how to resolve this?

0 Kudos
Message 1 of 24
(7,830 Views)

check this 

0 Kudos
Message 2 of 24
(7,813 Views)

Also this 

 

 

and this  

Message Edited by muks on 12-29-2009 11:36 AM
0 Kudos
Message 3 of 24
(7,812 Views)

Hello,

 

Do you get this problem when trying to build one of the NI-488.2 example programs?

 

If so, then we should be able to either reproduce the problem by compiling the example or offer pointers for how we were able to do it here.

 

Thanks,

Steven T.

0 Kudos
Message 4 of 24
(7,784 Views)

Hello everyone,

 

First, thanks for the responses. I really appreciate it. Normally, I'm one of the first to ask "did you check the FAQ or search the forums?" I did that, and didn't have any luck, which is why I posted this question. I still feel like an idiot/newbie though.

 

Let me answer all the responses:

 

Muks posted a link in the first response - I looked at that, and it just didn't seem to apply to me. My source code #includes ni4882.h, and my project links with ni488.obj. It didn't appear that I needed to do anything talked about in the link you posted. I don't have any NI-DAQ files installed. Oh, and that help file appears to show a Visual Studio 6 screen, although I don't think the help file indicates that is what it was (VS2008 looks a little different).

 

In the second response, muks posted two links -

 

In the first of those two links (here), the document talked about making sure GBIB-32.OBJ is linked. I do not have this file linked... I only have ni4882.obj linked. Seems to me I read one of the documents somewhere that suggested that the old include file (decl-32.h), and the old gpib-32.obj files, were replaced with the newer "ni4882" files, and that they were moved to a different location. What's interesting about this help document, is that its suggested that files might be located in "C:\Documents and Settings\All Users\Documents\National Instruments\NI-488.2\Languages". I had no files in that location at all, and honestly, that seems like a strange place to put NI files. I wouldn't have even looked there.

 

In the second link (here) - This is another document that talks about making sure the correct object file, and header files are included in your project. Notice, this document makes no reference to "documents and settings" as a possible location for these files. But yes, these steps were already done.

 

Steven T asked if I tried any of the sample code. Steven, I couldn't locate any Example code on my computer after installing the latest NI software (maybe I didn't ask for it during the installation? I just don't know). If you have a link where I can download and try them, I'll be happy to do that.

 

Here's what I can say so far:

 

(1) if I include the "ni4882.h" file, and link my application with "ni4882.obj", I get those errors

(2) if I include the "ni488.h" file, and link my application with "ni4882.obj", I get those errors

(3) if I include the "ni4882.h" file, and link my application with "gpib-32.obj", the progam compiles!

(4) if I include the "ni488.h" file, and link my application with "gpib-32.obj", the progam compiles!

 

Oh, and for kicks, I looked at my old Visual Studio 6 application, and it behaves the same way. It likes being linked with gpib-32.obj, but not with ni4882.obj

 

Thanks folks!

 

0 Kudos
Message 5 of 24
(7,766 Views)

Hi Bob,

The examples should be located in National Instruments\NI-488.2\Examples. When you install the NI 488.2 driver can check to include support for different test based ADEs. You can modify your installation in add/remove programs to add this feature. Let us know if you still can’t find the examples.

Matt
Applications Engineer
National Instruments
0 Kudos
Message 6 of 24
(7,717 Views)

Hello Bob,

 

The example programs are linked from the Start menu (Start>>Program Files....<Insert Matt W.'s path here>).  To compile them you must create a project and include the desired .obj file as well as the ni4882.h file.

 

Matt and I tried a few things (visual studio 2005 and visual studio 2008)and we were able to get our example programs to compile.  We created a simple console application with no precompiled headers and everything compiled and linked immediately (after including the ni4882.obj and ni4882.h files).

 

I can zip up the projects that we used and attach it here if it would help.

 

Thanks,

Steven T.

0 Kudos
Message 7 of 24
(7,687 Views)

Thanks everyone.. yes, I found the samples. Duh. not sure why I didn't notice them before.

 

Ok, here's what I did to try to recreate my problem. First, I started with the exampe file "4882Query.c", which was in the "Standard C" folder in the examples.

  

Using Visual Studio 2008, using 4882Query.c and linking ni4882.obj in each case:

 

Test case #1:

 

(1) Create an "empty console project"

(2) Added 4882Query.c to project

 

Project compiled fine!

 

Test case #2:

 

(1) Created an "Win32 project" (allowing VS2008 to create all the default files)

(2) Added 4882Query.c to project

(3) Renamed "main" in 4882Query.c to something else (so I would be treated as "just another function")

 

Project compiled fine!

 

Test case #3:

 

(1) Created an "empty Win32 Project". Project settings "Use Standard Windows Libraries"

(2) Added 4882Query.c to project

(3) Renamed main() to WinMain() in 4882Query.c

(4) Added "#include windows.h".

 

Project compiled fine!

 

Test case #4:

 

(1) Altered project settings from test case #3 to "Use MFC in a Static Library"

(2) Replaced "#include windows.h" with "#include afxwin.h"

(3) Compiler complained about ".c" as the extension, so source file was renamed to ".cpp".

 

Project build failed, with the errors I mentioned at the beginning of this thread

 

I'm beginning to think my problem is somehow related to the use of MFC (and possibly me not quite understanding the proper way to use MFC).

 

Thanks everyone.

 

 

0 Kudos
Message 8 of 24
(7,676 Views)
Solution
Accepted by topic author BobSpiral

Hello BobSpiral,

 

I have the same problem. I use Visual C++ 2008 SP1 with NI-488.2 library ver. 2.7.3.

 

Please check whether your program is compiled with "/MD"(or "/MDd") compiler option.

 

I encountered LNK2019 (unresolved external symbol) error when a program was compiled with "/MT"(or "/MTd") compiler option(using static CRT library).
When the program was compiled with "/MD"(or "/MDd") compiler option(using DLL CRT library), the build steps were passed with no error.

 

I presume that some functions of DLL version CRT are called in "ni4882.obj" module.
And that, it seems to me, is the reason why LNK2019 error occurs.

 

If the program is compiled with "/MT[d]", the import library of CRT DLL is not linked by linker.
So linker cannot resolve the symbols of import functions (__imp__****) of CRT DLL in "ni4882.obj", therefore LNK2019 error occurs.
I'm just guessing.


Excuse me for my poor English and handwriting.

 

Thanks,

Noraneko

0 Kudos
Message 9 of 24
(7,544 Views)

Noraneko wrote:

 

Please check whether your program is compiled with "/MD"(or "/MDd") compiler option.

 


I think this may be the answer! Yes, I do compile my programs with the "static" version of the libraries (so I don't have to worry whether or not the end-user has the required DLLs installed on their system. I know.. they should, but I've had problems in the past where they did not).

 

When I changed my project to use the "DLL library", it compiled just fine.

 

Thanks Noraneko!

 

Soooo, is there a way to get around this requirement?

 

 

0 Kudos
Message 10 of 24
(7,531 Views)