I want to build a DLL to use it as an IIS/ISAPI application. So far so good. It works. However, I have to drag arround the runtime dll and other dependencies (like some boost libraries).
I would like to make a single DLL (in order to ease the deployment on multiple servers).
So I changed the switch from /MD to /MT. However, now I get errors of duplicate symbols during link. For example :
msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: void __thiscall std::basic_ostream<char,struct std::char_traits<char> >::`vbase destructor'(void)" (??_D?$basic_ostream#DU?$char_traits#D#std###std##QAEXXZ) already defined in gateway.obj
I'm puzzled that /MD or /MT are compiler flags and not linkers flags. And it could in some way explain why I get duplicated symbols (as the will be included in each .obj).
So the question is: how do I configure visual studio 10 in order to get a dll that includes all its dependencies.
The /MD and /MT switches only apply to the Microsoft C runtime library and not 3rd party libraries. This documentation gives some information on why it is a compiler switch (they cause different defines to be created during the compilation).
Pulling 3rd party DLLs directly into your own DLL as static libraries is probably not a simple process unless static libraries already exist. I don't know of any standard method for turning a DLL into a static library. A quick Internet search indicates that there exist tools that claim to do that process (my quick search did not turn up any free ones). But I think the most robust solution would be to use existing static libraries if you can. I believe you can build static versions of the Bools libraries, which you could then specify in your link statement in Visual Studio (as opposed to naming the libraries for the DLLs).
Related
I have an old project that I need to revisit. It was built in some version of Visual C++ (prolly 2005) looking at the .sln file. The sln file wont get converted to a VS 2008 solution due to some corruption (dubug point -1). I imported the folder in VS as a new project and tried compiling.
It gave compilation errors for "lang/Typedefs.h/Assertions.h" not there. Removing the declarations I had errors for Uint8/16/32/64 not declared. So I added the typedefs and other macros (TOOLS_UNUSED_PARAMETERS(x) / TOOLS_FORBID_COPY()).
That being ironed out, I got errors for Gui/FileDlg.h and Gui/FolderDlg.h(debug point - 2).
I didnt find any of those header files from any resources online or in my current VS installation and so I am assuming that code is missing and I will have to redo it.
Even these could probably have been custom implemented by the earlier programmer. The current MFC uses CFileDialog and the code uses Gui::FileDlg.
I commented out the code for the time being to see where can I get to since gui is not that big a part of the application. Later I see linker errors corresponding to RegKeyOpenEx calls and outputstream calls(dubug point -3). Winreg.h was not included but windows.h was.
sample :
Error 2 error LNK2019: unresolved external symbol __imp__MessageBoxA#16
referenced in function "public: class std::basic_ostream<char,struct
std::char_traits<char> > * __thiscall FileManager::getOutputStream(class Interface
*,class LogPoint *)" (?getOutputStream#FileManager##QAEPAV?$basic_ostream#DU?
$char_traits#D#std###std##PAVInterface##PAVLogPoint###Z) filemanager.obj
PCAPGenerator
I am not a .Net programmer so can you please suggest what would be the right course of action here ?
which debug points should i be focussing on.
RegKeyOpenEx is a Winapi function defined in Advapi32.dll. To link that into a Visual C++ project:
If your project is a static library (right-click project->Properties->Configuration Properties->Configuration Type->Static Library (.lib), go to Configuration Properties->Librarian->General->Additional Dependencies and add Advapi32.lib.
If your project is a dll (same place, says Dynamic Library (.dll) instead), you'll have the Linker section instead of Librarian. Go to its Input subsection, and add Advapi32.lib to Additional Dependencies.
For your remaining linker errors, proceed in the same way: go to the MSDN doc for the function, check which dll/lib it belongs to and have your project link it in as described above.
When developing and deploying native Windows applications, I often need to install a runtime before being able to run my binary, or statically link the library with my binary. For instance, after building a "Win32 Console" project with Visual Studio 2008, attempting to run the program on a fresh Windows 7 image results in:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
Issues like this one have been brought up in other posts on StackOverflow.
How does one develop applications that don't require runtimes that aren't already on the target OS (i.e. don't require installing redistributable packages or private/shared side-by-side assemblies)? How does one avoid using msvc[mpr]90.dll and just use the Windows API in \windows\system32*.{dll,sys}?
I'm thinking along the lines of the code that comes out of the demoscene, but that's frequently not made available.
Others have already responded with respect to linking CRT statically. If you also want a small binary at the same time, then your best bet is forego CRT entirely, and use only Win32 API functions as much as possible. You'll still get some CRT code, most notably related to startup (i.e. that which calls main) and shutdown (atexit handling etc), but otherwise the linker won't link CRT functions that you do not use.
You can avoid linking CRT altogether by using /Zl compiler switch. This means that main will no longer work, however - you'll need to define WinMain (name doesn't matter, but signature must match, and it must be __stdcall), and you will have to specify the name of your WinMain-like function as an entry point via linker /entry: switch. This will save you ~30Kb of CRT code (tested on a .cpp with an empty main).
If you go the latter route, you might also have to deal with issue of compiler intrinsics. There are some functions that are nominally defined by the CRT (and declared in its headers), but which are treated specially by the compiler, so that it inserts optimized assembly instructions at the point of the call where possible - examples are memset, strlen, and a good chunk of functions in <math.h>; a complete list can be found here. Since you don't have CRT, if you need these functions, or could avoid it but prefer the intrinsic because of improved performance (hard to do better than memset, for example), then you have to declare them yourself, and use #pragma intrinsic. E.g.:
// Contains macros and typedef only, so safe to include without CRT.
// We need it here for size_t.
#include <stddef.h>
extern "C"
{
int abs(int);
void* memset(void*, int, size_t);
}
#pragma intrinsic(abs, memset)
int __stdcall main(void*, void*, char*, int)
{
char tmp[10];
memset(tmp, abs(-123), 10);
return 0;
}
The above can be compiled with:
cl /c /Zl foo.cpp
link /entry:main foo.obj
Link the CRT statically via the /MT switch (and likewise MFC, if you're using it).
Static linking limits what you can do with DLLs somewhat, but for simple executables it works like a charm. (And if you're shipping DLLs, you can always ship private assemblies anyway.)
Use the static CRT. This doesn't create a dependency on msvc*.dll. The CRT is linked directly into your program. This doesn't create dependencies, but does increase the size of your executable.
More info on different CRT options here.
Statically link the runtime. MS Visual C++ has option /MT for that (default is /MD)
I think one way to do this is to just not use Visual Studio and instead rely on the command line SDK tools. (You can alternatively figure out how to config VS to do what you want, but that seems harder.) E.g.:
cl /c app.cpp
link app.obj ws2_32.lib
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.
Which headers should I not use if I don't want my program to be linked with any of msvc*.dll ?
At the moment my application uses:
kernel32
user32
shell32
msvcp90
msvcr90
I want to get rid of the bottom two files. I don't mind if I will have to rewrite certain aspects of the program.
Because I know if you code in C and then link it won't link any msvc's
I believe you have to change the way the CRT is linked into your program. I think for that you have to change the C++->Code Generation->Runtime-Library to the static version. This is for Visual Studio 2005, don't know about newer versions.
Those libraries contain the C++ runtime - heap management and other stuff hard to get rid from.
You could link the C++ statically instead - use "C++ -> Code Generation -> Runtime Library" setting. Then you will not need those .dll files. However this is not the recommended way - if a vulnerability is found in the C++ runtime you'll have to recompile and reship your program.
Static link is the right answer. A related bit of advice is to use depends.exe to see what functions your exe is actually hitting in the dependent dlls. Those dependencies might be due to explicit use on your part or due to CRT implementation that you don't explicitly invoke.
I'm trying to use a static library created by me in Visual C++ 2005 (unmanaged C++). I declare one function "int myF(int a);" into a .h file, I implement it in a .cpp file, I compile it - the .lib file is produced.
I create a new project (a separate solution) in VC++ 2005 (also native C++), I add the paths for the include file and the lib file; when I invoke the function myF the linker reports an error: "error LNK2019: unresolved external symbol _myF referenced in function _main". if I create the client project in the same solution as the library project and then add a reference to the library projects, it works, but I'm not going to implement everything like this, but rather to add external libraries to my projects...
What is wrong?
Thank you.
You need to also include the actual .lib file in your 2nd project (not just the path to it).
There should be an option in the linker settings to do this.
It is not sufficient to list the folder in which MyStatic.lib can be found. You have to explicitly tell the linker that Dependant.vcproj is using MyStatic.lib.
In VS2005 you do this by project properties->Linker->Input->Additional Dependencies. You can also sprinkle some preprosessor stuff in the .h file to tell the compiler to tell the linker to use MyStatic.lib.
Edit:
The preprocessor magic goes like this
#pragma comment(lib, "MyStatic.lib")
(EDIT: This was a response to the question of getting the /NODEFAULTLIB error in link phase which has now been deleted... shrug)
You are mixing compiler settings if your are getting the defaultlib error. For example, if you build your library in debug and the build your main in release, you will get this error since they are built to use different versions of the CRTL. This can also happen if you use different settings for linking with the C Runtime as a object library or as a DLL. (See the C/C++ options, the "Code Generation" section, under the "Runtime Library" setting)
In many projects there isn't much you can do if you can't correct the settings of the library (for example, 3rd party libraries). In those cases you have to use the /NODEFAULTLIB switch which is a linker option in the "Input" section called "Ignore Specific Library".
But since you are in control of both the main and the library, build a debug and a release version of your LIB file or make sure your "C/C++;Code Generation;Runtime Library" settings match in both projects.
Try setting additional dependencies in the linker input for a project properties.