Static linking to MFC/CRT and Standard C++ libraries

[Dilip]

I am in the process of writing a tiny MFC application (developed on
Visual Studio 2008) that (for reasons that are too confusing to list)
cannot rely on the appropriate redistributables present on the target
machine. I cannot do the obvious thing of shipping the
redistributables along with application. Please lets not get into the
why of it because I am stuck in a weird situation.

As a result my only option is statically link against everything. To
that end my application statically links against MFC. So far so
good. However, I also use a lot of standard C++ features (including
stuff from tr1). I understand at run time my application is going to
go looking for msvcr90.dll and msvcp90.dll, correct? How do I
statically link against CRT and Std C++ libraries? I gather their
static counterparts are libcmt.lib and libcpmt.lib, right? Is it just
a question of putting these in the linker settings?

How can I achieve my objective?

[Scott McPhillips [MVP]]

Post by Dilip
I am in the process of writing a tiny MFC application (developed on
Visual Studio 2008) that (for reasons that are too confusing to list)
cannot rely on the appropriate redistributables present on the target
machine. I cannot do the obvious thing of shipping the
redistributables along with application. Please lets not get into the
why of it because I am stuck in a weird situation.
As a result my only option is statically link against everything. To
that end my application statically links against MFC. So far so
good. However, I also use a lot of standard C++ features (including
stuff from tr1). I understand at run time my application is going to
go looking for msvcr90.dll and msvcp90.dll, correct? How do I
statically link against CRT and Std C++ libraries? I gather their
static counterparts are libcmt.lib and libcpmt.lib, right? Is it just
a question of putting these in the linker settings?
How can I achieve my objective?

The setting to statically link to the runtime is in Project, Properties,
C/C++, Code Generation, Runtime Library.

[Dilip]

On Apr 8, 9:03 pm, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>

Post by Scott McPhillips [MVP]

Post by Dilip
I am in the process of writing a tiny MFC application (developed on
Visual Studio 2008) that (for reasons that are too confusing to list)
cannot rely on the appropriate redistributables present on the target
machine.  I cannot do the obvious thing of shipping the
redistributables along with application.  Please lets not get into the
why of it because I am stuck in a weird situation.
As a result my only option is statically link against everything.  To
that end my application statically links against MFC.  So far so
good.  However, I also use a lot of standard C++ features (including
stuff from tr1).  I understand at run time my application is going to
go looking for msvcr90.dll and msvcp90.dll, correct? How do I
statically link against CRT and Std C++ libraries?  I gather their
static counterparts are libcmt.lib and libcpmt.lib, right?  Is it just
a question of putting these in the linker settings?
How can I achieve my objective?

The setting to statically link to the runtime is in Project, Properties,
C/C++, Code Generation, Runtime Library.

To my surprise I found that under Release setting, the libraries were
statically linked by *default* (it was set at /MT). I never knew
this. I thought the default was always dynamic linking and you had to
deliberately convert it to static?

[David Lowndes]

Post by Dilip
To my surprise I found that under Release setting, the libraries were
statically linked by *default* (it was set at /MT). I never knew
this. I thought the default was always dynamic linking and you had to
deliberately convert it to static?

You can choose static linking during the pages of the Wizard, but I'm
fairly sure the default is to dynamic link.

Dave

[Dilip]

Post by David Lowndes

Post by Dilip
To my surprise I found that under Release setting, the libraries were
statically linked by *default* (it was set at /MT).  I never knew
this.  I thought the default was always dynamic linking and you had to
deliberately convert it to static?

You can choose static linking during the pages of the Wizard, but I'm
fairly sure the default is to dynamic link.
Dave

Thats what I am confused about too. When I first created the project
the wizard pages allowed me an option to statically link *only* with
MFC -- I didn't encounter anything regarding CRT. Oh well.. at this
point its mostly a curiousity issue.

[David Lowndes]

Post by Dilip
Thats what I am confused about too. When I first created the project
the wizard pages allowed me an option to statically link *only* with
MFC -- I didn't encounter anything regarding CRT.

I think the 2 things are combined at that stage.

Dave

[Alex Blekhman]

Post by Dilip
I cannot do the obvious thing of shipping the
redistributables along with application. Please lets not get into the
why of it because I am stuck in a weird situation.

In addition to Scott's answer. Shipping the redistributables is not so
obvious anymore (and never been for that matter). Sometimes you need to
deliver small tool or package, which should be as independent of
surrounding environment as possible. No installation, no dependencies.
Lately, with all this manifest thing, delivering of an application no
matter how small suddenly became less than trivial. With modern cheap
and huge disks static linking became popular once again.

Alex

[Martin B.]

Post by Dilip
I cannot do the obvious thing of shipping the
redistributables along with application. Please lets not get into the
why of it because I am stuck in a weird situation.

(...) which should be as independent of
surrounding environment as possible. No installation, no dependencies.
Lately, with all this manifest thing, delivering of an application no
matter how small suddenly became less than trivial. With modern cheap
and huge disks static linking became popular once again.

Correct me if I'm wrong, but isn't statically vs. dynamically linking
also a memory issue? (Not for the single tiny app, but for the overall
system)
When "all" small Tools and Services on the system use the DLL runtime
library this DLL only has to be loaded into RAM once, right? However, if
"all" stuff uses static linking, all the rt code has to be loaded
multiple times?

cheers,
Martin

[Alex Blekhman]

Post by Martin B.
Correct me if I'm wrong, but isn't statically vs. dynamically linking
also a memory issue? (Not for the single tiny app, but for the overall
system)

You're correct. Static linking is slightly wasteful, since otherwise
common library will be loaded time and again for every statically linked
application. This tradeoff is not new, however. Simplified delivery
versus small code bloat - you decide what is more important to you. With
today's personal computers another couple of KB's (or even MB's) for
executable image is negligible. For example, my home desktop box has 6GB
of RAM and my office machine brandishes mighty 12GB of RAM. Who cares
about another 30KB for an executable?

OTOH, handheld devices impose much more strict limitation for running
application. So, every saved KB of memory counts. As I said in the
beginning of this post, YMMV.

Alex

[Dilip]

Post by Alex Blekhman

Post by Dilip
I cannot do the obvious thing of shipping the
redistributables along with application.  Please lets not get into the
why of it because I am stuck in a weird situation.

In addition to Scott's answer. Shipping the redistributables is not so
obvious anymore (and never been for that matter). Sometimes you need to
deliver small tool or package, which should be as independent of
surrounding environment as possible. No installation, no dependencies.
Lately, with all this manifest thing, delivering of an application no
matter how small suddenly became less than trivial. With modern cheap
and huge disks static linking became popular once again.

Alex
That is *exacty* my situation. Although I worked with C++/VC++ for
most of the 90s, working in the .NET world for the past several years
have made me forget some routine things in the VS properties dialog.
I am glad to know its not so weird anymore to distribute statically
linked apps.

Thanks!