0

I am writing lib files in VS that have to be imported into CVI. Recently a linker problem occured.

It says that _allmul() is an undefined symbol.

_allmul() and freinds are implemented as calls to the CRT library functions to handle various 64bit operations.

The lib file that i write is static because i want all the code to live inside it. Linking with VS is no problem and all unittests pass.

Linking with the CVI-IDE leaves the CVI Linkter complaining about an unresolved _allmul().

I thougth that setting the /MT switch in VS is enough to make the CRT link statically, this seems to be wrong.

Why is my assumtion wrong? How can i link the CRT calls statically?

Edit:

Here is a short demo of a project that i can compile in VS2010 but that i can not link to in CVI The following is compiled as a LIB project:

HEADER 

void print( unsigned A, unsigned B );

CODE

#include "MyprintInterface.h"

#include <stdio.h>

void print( unsigned A, unsigned B ){
    long long copyA = ( long long ) A;
    long long copyB = ( long long ) B;
    printf_s( " %lli * %lli = %lli ", copyA, copyB, copyA * copyB ); 
    // copyA * copyB -> this invokes allmul
    // printf_s this is a ms specific function
}
Johannes
  • 6,490
  • 10
  • 59
  • 108
  • Use the vendor's support forums to find help. – Hans Passant Jul 05 '13 at 15:50
  • There isnt really a lot stuff about CRT out there, so i am hoping to get a general solution here. I already solved the specific problem simply by implementing my own 64 bit multiplication function - i am not really interested in CVI but the internal mechanisms of CRT linking do interest me a lot. – Johannes Jul 05 '13 at 16:04
  • I now experience simmilar problems with symbol '_snprintf_s'. i assume the two problems have a common source. – Johannes Jul 11 '13 at 07:38
  • It may be a matter of including the correct files. I think i have the same issue with printf, but since both compilers supply their version of stdio.h i dont recognize that a different file is linked. This may lead to compatibility issues. – Johannes Jul 15 '13 at 10:32

1 Answers1

1

This is a little late, but maybe it will help someone else.

I had very similar experience when using the gSoap toolkit with LabWindows/CVI. The toolkit generates ANSI C bindings used in creating web service clients or servers. However it sometimes generated versions of MS functions (some deprecated) that were prototyped slightly different than those in CVI. Solving this was kind of tedious, but generally followed these steps:

1) install appropriate Microsoft SDK onto your dev box. Here is one option for Microsoft SDKs. (There are others, Google it)
2) search MSDN website for the unresolved symbol to determine what .lib/.h support it. (MSDN list of variations of sprintf, for example)
3) include any required .lib/.h files.
4) make sure msvcr80.dll or msvcr100.dll (or other as appropriate) are visible to your executable. (i.e. place either in the executable run-time directory, or in the system directory.)

In addition to this I had to bring some of the #defines from the header files supporting file write/read functions, just for example: 

#define _O_TEXT         0x4000  /* file mode is text (translated) */     
#define _O_BINARY       0x8000  /* file mode is binary (untranslated) */

And: (Requires Microsoft Platform SDK be installed c:\program files\microsoft platform sdk\include\crt (copied to project dir and included in project)) 

  fcntl.h  (definition for file mode etc., _O_BINARY)
  float.h  (definition for isnan etc.)
  io.h     (definition for setmode etc.)

Also, there is an example CVI project with source code illustrating what I have described above, (including using crt) here.

[EDIT] Regarding COFF compatible .libs when using third party libraries with respect to LabWindows/CVI - Read the posts here.

[EDIT 2] Once you install the Windows SDK, the headers for everything in msvcrxxx.dll will be on your system. But for finding .h dependancies of a specific API call I typically have good luck just searching for it on Google: i.e. for sprintf_s et. al., the first link returned was this. It includes notes on how to use sprintf_s including source code.

As for allmul issues, I have not run into this before, but this guy did.

ryyker
  • 22,849
  • 3
  • 43
  • 87
  • I will try this solution soon to see if it removes my errors. I still have a demo project set up where i can test my usecase. – Johannes Aug 20 '13 at 16:39
  • Okay, good luck. I will monitor this if you have any more specific questions. by the way, if you are not familier with creating CVI compatible .libs, I am editing my post to include a link on how, but in short, in the editor, click in the header file you need the .lib for, click Options->Generate DLL Import Library... Follow the default prompts. – ryyker Aug 20 '13 at 20:43
  • my biggest problem is getting the header file. If i use dependency walker to look inside of msvcr100.dll i can see the functions i want like sprintf_s. But how do i get the header without writing it myself? Another thing would be allmul, those are not even "real" functions. – Johannes Aug 21 '13 at 09:17
  • i was unable to get the allmul part - do you have a working approach for that? – Johannes Aug 22 '13 at 17:48