MS C/C++ Linkeroption /MT but still unresolved _allmul() when linking with different IDE

Question

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
}

Answer 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.