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]]

"Dilip" <rdi...@lycos.com> wrote in message
news:844504f4-154f-4227...@g10g2000yqh.googlegroups.com...

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

--
Scott McPhillips [VC++ MVP]

[Alex Blekhman]

On 09-Apr-10 4:08, Dilip wrote:
> 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.]

Alex Blekhman wrote:
> On 09-Apr-10 4:08, Dilip wrote:
>> 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

[Dilip]

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!

[Alex Blekhman]

On 09-Apr-10 11:53, Martin B. wrote:
> 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]

On Apr 8, 9:03 pm, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>
wrote:
> "Dilip" <rdil...@lycos.com> wrote in message

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]

>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]

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]

>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