What's static link at runtime?

[BekTek]

When I build boost libs,
I realized that there is static link at runtime..

What does that mean?

I thought static linking is done at compile time.
Am I wrong?

 

[Phlip]

When I build boost libs,
I realized that there is static link at runtime..

What does that mean?

I thought static linking is done at compile time.
Am I wrong?

<warning value="platform specific">
Uh, all platforms I know support this feature,
but C++ itself does not define it, so YMMV.

You can build a library to link statically, as a LIB,
or dynamically, as DLL. The former links at link
time, and the latter links after you double-click on
an executable but before any of the executable's
opcodes evaluate.
</warning>

Many libraries provide both LIBs and DLLs, so the end-programmer can pick if
they want executables that are easy to install or small, respectively.
However <deep breath> The C++ Standard does not define LIBs or DLLs (or .a
and .so files), so future discussions about them belong on any newsgroup
except this one.

 

[JXStern]

When I build boost libs,
I realized that there is static link at runtime.

What does that mean?

I thought static linking is done at compile time.
Am I wrong?

....

There's coding time.

There's compile time.

There's link time.

There's load time.

There's run time.

On various systems you can get linkages resolved on at least the last
three times, depending on just what kind of components are involved.
There's not a lot of linking as such as compile time, that's why you
have header files and typelibs and whatnot.

J.

 

[Michael Kurz]

...

There's coding time.

There's compile time.

There's link time.

There's load time.

There's run time.

On various systems you can get linkages resolved on at least the last
three times, depending on just what kind of components are involved.
There's not a lot of linking as such as compile time, that's why you
have header files and typelibs and whatnot.

Windows supports even to resolve at runtime, as the loader supports a
"DELAY_LOAD", which causes the dynamic library being loaded, when the 1st
function call to it is invoked.

(Or you can control library loading manually of course.)


Regards
Michael

 

[JKop]

BekTek posted:

When I build boost libs,
I realized that there is static link at runtime..

What does that mean?

I thought static linking is done at compile time.
Am I wrong?

Consider the C++ Standard Library; When you compile a Win32 program, you've
the choice to link with it statically or dynamically. If you analyze the two
different executables, here's what you see:

Statically:

Bigger executable.
When opened in dependency walker, it shows no more dependancies than the
ones you yourself use in the program.

Dynamically:

Smaller executable.
When opened in dependancy walker, it shows a dependancy, a file called
something like "MSVCRUN.DLL". So when you use a Standard C++ Library
function, it's calling it from this DLL file. Here comes a bit of a paradox
now. Even though I'm saying that this is "dynamic" linking; in the world of
Win32, it's actually referred to as "static" linkage. What's referred to as
"dynamic" linkage in Win32 programs is achieved as follows:

HMODULE hDLL = LoadLibrary("name.dll");

It's all relative!


-JKop

 

[Howard]

BekTek wrote:

You can build a library to link statically, as a LIB,
or dynamically, as DLL. The former links at link
time, and the latter links after you double-click on
an executable but before any of the executable's
opcodes evaluate.
</warning>

I don't know about you, but when I use a DLL, I often explicitly load it in
run-time code, then get the address of the function I need to call, then
call the function. Saying that it links "before any of the executable's
opcodes evaluates" doesn't sound correct to me. Wouldn't it have to wait
until I make the call to load it? (Otherwise, whatever would the call to
load it be doing?)

-Howard

 

[Richard Herring]

I don't know about you, but when I use a DLL, I often explicitly load it in
run-time code, then get the address of the function I need to call, then
call the function. Saying that it links "before any of the executable's
opcodes evaluates" doesn't sound correct to me.

In that case, it wouldn't be. But many of the static LIBs you link
against are merely tables of contents for the corresponding DLLs, and
*those* DLLs get loaded automatically as described above.

 

[Michael Kurz]

I don't know about you, but when I use a DLL, I often explicitly load it in
run-time code, then get the address of the function I need to call, then
call the function. Saying that it links "before any of the executable's
opcodes evaluates" doesn't sound correct to me.

But loading a DLL "manually" is a different way then linking the DLL, which
means entering all used symbols to the Import Address Table of the
executable, which is used by the loader later on.

In a typical windows application no code from within the executable is
executed before all (linked) DLLs are loaded, because the loader will load
all DLLs before it starts to execute the entry point (typically CRT main,
which does the initialisation and calls your int main() afterwards). But as
windows DLLs have a main (entry point) as well (which is e.g executed when
the dll is loaded), someone could execute code located in the executable
from such a dllmain(). To achieve this you need to know what to execute, so
the executable need to export symbols, which can be found from other modules
(DLLs), which means you can call a GetProcAddress(...) and get the address
of the exported symbol.
In such cases code from within the executable is executed before all linked
DLLs are loaded.

If you think this sounds very constructed, well there are executables out
there, which do exactly this, but
I have no idea why ;-)

Wouldn't it have to wait
until I make the call to load it? (Otherwise, whatever would the call to
load it be doing?)

If you are using LoadLibrary() everything is under your control and you are
responsible for providing valid function addresses before you call them.


Regards
Michael