Statically linking libraries

[tummychow]

OK, so when you complete a program and compile to executable, you can't just run it on other peoples' computers because they don't have the libraries. Some compilers such as VC++ come with a redistributable that the user can install to operate any program compiled therein. But I have also heard of an alternative method that packs the libraries into the program, rendering it self-contained.
So my question is, how do I go about doing this? (And for specifics, how do I do it in VC++ 08 Express?)

[Bazzy]

The title answers your question, link all the library statically

[tummychow]

Yes but how do I go about the task? What are the steps?
Sorry if my question was a little vague, I know the concept but not the mechanics.

[webJose]

Open the C++ project properties:

If using MFC:
• Configuration Properties -> General: Where it reads Use of MFC, change to Use MFC in a Static Library.

If using ATL:
• Configuration Properties -> General: Where it reads Use of ATL, change to Static Link to ATL.

The CRT:
• Configuration Properties -> C/C++ -> Code Generation: Where it reads Runtime Library, change to Multi-Threaded (/MT).

The manifest must go:
• Configuration Properties -> Manifest Tool -> Input and Output: Where it reads Embed Manifest, change to No.


All this in Visual Studio Professional 2008. I have heard MFC is not available in the Express edition. Maybe ATL is also not available.

[tummychow]

What about plain console, neither MFC nor ATL?

[Bazzy]

Options for the std library: http://msdn.microsoft.com/en-us/library/2kzt1wy3%28VS.71%29.aspx

[tummychow]

Thanks! I presume that the option in question is /MD?

[Bazzy]

Nope,
/MD :

The actual working code is contained in MSVCR71.DLL, which must be available at run time to applications linked with MSVCRT.lib.

/MT is the right one

[tummychow]

I see, thanks!
Sorry to drag this question out but then, if I set that compiler option and compile, I'll get the behavior I desire?

[Bazzy]

Yes

[tummychow]

Beautiful, thanks.

[1yR4jE8b]

I always liked GCC/++ for this, because, unlike Microsoft's compiler which requires the runtime library to be installed, it links standard library functions statically so the executable is stand-alone. Of course this only applies if you are using standard libraries.

This leads to larger code, but honestly, how much smaller are Microsoft executables if you take the size of the runtime into account, and it's much easier to distribute because you don't have the MS runtime as an external dependancy.

Of course, this kind of goes out the window when working with libraries like Gtk+ and QT which are coded around dynamic linking.

Long story short: While static linking is nice, there really is no way to completely do away with dynamic linking so you might as well learn how to do it sooner than later.

[webJose]

In percentage change, the change in filesize is dramatic if you drop MFC in. Example: Simple internet downloader tool written with a few MFC classes (CString and such). The console application was 10KB when linking dynamically; it was, however, 240KB when compiled statically. Yes! 2400% change.

[jsmith]

Though an extra 230K can be irrelevant for a large application. And file size is pretty irrelevant anyway; the real
benefit is if every app statically linked the library, then there would be 1 copy of the library in RAM for each
process using it, which is wasteful.

But it should be noted that even gcc/g++ dynamically links against the C/C++ runtime libraries by default. You can
see this by running "ldd" on your favorite app. It will show you what .so files the application will load at runtime.

[helios]

2400% change.

No. It's a +230K. The increase isn't in relative to the size.

the real benefit is if every app statically linked the library, then there would be 1 copy of the library in RAM for each process using it, which is wasteful.

I'm not sure Windows can do that.

[webJose]

jsmith: True, but you are assuming that the overhead for any project will always be 230KB. I believe that assumption is incorrect, as the compiler will add the used code only. Those 230KB were for just the few classes used. What if you use 20 or more different classes? The overhead will be larger.

helios, my bad for not subtracting the original file size. So it is a 2300% change. Is that what you meant?

[helios]

Those 230KB were for just the few classes used. What if you use 20 or more different classes? The overhead will be larger.

Wrong. Standard classes are included completely in the standard headers. It's true that using more classes will increase the code size, but that will happen regardless of how the runtime is linked. The runtime contains code for I/O and other things related to interaction with the OS. Linking it statically is a one time cost. That's what I meant when I said "+230K". It's 230K regardless of what the project contains.

[webJose]

I see. I was under the impression that only the code required to make the EXE work was really added.

Does this happen for any static library? If I create a static library with 100 classes, and create an EXE that uses 2 of them, will the 100 be included?

[helios]

Unless the linker is configured to remove unreferenced symbols, yes. Even with that optimization, there's no guarantee that it will actually be able to remove them.