It appears that the Windows x64 version (at least) of ni4882.obj was compiled with the /MD option to require linkage with the import libraries for the dynamic (DLL)-based C runtime. This was not true of the older gpib-32.obj library for Win32, and it's a problem in my case because the project I'm working on requires /MT linkage with the static runtime libraries. Attempting to link ni4882.obj with my x64-based C module yields the following:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl -Zi -Od -DDEBUG -MTd -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -G
S- -D_AMD64_=1 -fp:fast -DWIN64 -D_WIN64 -W4 -D_CRT_SECURE_NO_DEPRECATE -DTLS_
THREAD_UNSAFE -DBUILDING_TLL -I..\.. -I..\shared DTS2070.cpp -FoDTS2070_64.obj
link /DEBUG /NODEFAULTLIB:libcmt.lib /MACHINE:X64 /INCREMENTAL:NO /NOLOG
O -dll -libpath:..\.. kernel32.lib ws2_32.lib mswsock.lib advapi32.lib user32.li
b gdi32.lib comdlg32.lib winmm.lib shell32.lib setupapi.lib shell32.lib -out:DTS
2070_64.tll ..\shared\ni4882.obj DTS2070_64.obj DTS2070.res
Creating library DTS2070_64.lib and object DTS2070_64.exp
ni4882.obj : warning LNK4217: locally defined symbol _time64 imported in functio
ni4882.obj : warning LNK4217: locally defined symbol rand imported in function L
ni4882.obj : warning LNK4217: locally defined symbol srand imported in function
I'd rather not make my application depend on the DLL-based C runtime libs just to provide _time64, rand() and srand() to ni4882.obj. Can someone please have a look at this and either recompile ni4882.obj for static linkage as the older libraries were, or let me know what I'm doing wrong?
I hope you are doing well today! I do have a few questions for you regarding your current configuration. First, what versions of Measurement Studio and Microsoft Visual Studio are you using? Also, what x64 Windows operating system are you developing on? I have attached a link below to more information about our Measurement Studio support for legacy environments, which explains more about the support that we offer for legacy environments and languages. Please take a look at this article, and let us know what versions of Measurement Studio and Visual Studio you are currently using. Thanks, John! Have a great day!
I'm not using Measurement Studio as such, but there appears to be no other support forum for the NI488.2 drivers. This is for development under Windows 7 64-bit, with Visual C++ 2010. (It's not a legacy issue at all, quite the contrary.)
Does your code compile successfully with including the MSVCP100.DLL? (http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=VS.100%29.aspx). It does seem like the /MD compile option requires this file.
What version of 488.2 driver do you have? What version do you think was compiled with different options?
NI Americas | AE
NI.com/support | 1866-275-6964
Hi, Michael --
That's what I'm saying... it works fine with /MD, which causes it to link with the import libraries for the DLL runtimes. There are no warnings in that case. However, my project does not use the DLL-based runtime libraries -- it uses the /MT option for static linkage with LIBCMT.LIB. The warnings occur because you used /MD when you compiled that module, which causes the linker to pull in the MSVCP100.DLL import library. That in turn makes the _time64, rand, and srand names appear twice, in both 'imported' and statically linked forms, which triggers the linker warnings.
The module in question is the copy of ni4882.obj that's installed in C:\Program Files (x86)\National Instruments\Shared\ExternalCompilerSupport\C\lib64\msvc when you install the 2.8 driver package from http://zone.ni.com/devzone/cda/tut/p/id/5326 .
This was never an issue with the 32-bit gpib-32.obj file -- it only started cropping up when I recompiled for x64.
Both gpib-32 and ni4882 were built using the same options but ni4882 is using additional functions that appear to be causing issues for you. Why do you want to avoid making your applicaiton depend on the DLL version of the C Runtime?
Hi, Michelle --
It's not a huge deal, since the linker will do the right thing either way. It will just give a warning when functions that were declared with __declspec(dllimport) due to the use of /MD are found in a static library at link time. Ignoring the warnings only costs a few extra cycles at runtime when rand(), srand(), or time() is called, but I wanted to make sure you didn't have a static version available somewhere else that would avoid the issue entirely. I'd say don't worry about it at this point, given that no other users have mentioned the problem.
The project is close enough to shipping that I'd rather not make a global change to its CRTL linkage options to get rid of the warnings, especially since GPIB support is a small part of the overall package. The use of the DLL-based runtime complicates the installation process somewhat, in that some extra redistributable files have to be shipped with the product and handled by the installer.
we have also a similar problem. We are using Visual Studio 2017.
In this case it is more critical, because we receive link errors.
The issue occurs on both 32-bit and 64-bit platforms.
For this project, a static runtime library linkage is required (/MT option of Visual Studio has to be used).
We are linking the ni4882.obj file provided in the "ExternalCompilerSupport" directory.
Would it be possible for you to provide a ni4882.obj-file which is using static C runtime library linkage (/MT option)?
1>------ Rebuild All started: Project: ..., Configuration: Release Win32 ------
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__fread
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__fopen
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__strncat
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__rand
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__srand
1>ni4882.obj : error LNK2001: unresolved external symbol __imp__time
1>... fatal error LNK1120: 6 unresolved externals
1>Done building project "....vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Thank you much,