Compiling and linking libraries

[Mike Parker via Digitalmars-d-learn]

On Sunday, 20 November 2016 at 01:01:16 UTC, Darren wrote:
>
> Thank you for this!  Great information.
>
> So dub dynamically "add" code from the dll into the source code 
> at runtime?

No. DUB doesn't have anything to do with runtime and doesn't know 
anything about the DLLs you use. The Derelict packages all rely 
on a core package called DerelictUtil. It uses the system APIs to 
load the DLL when you call the load method on a Derelict object 
(DerelictGLFW3.load, DerelictGL3.load, etc...)

> Also will I ever need to learn how to use static libraries and 
> is there a reason to?

When you add any Derelict package as a dependency to your 
project, you're using a static library. That is, DerelictGLFW3 
and DerelictGL3 and all Derelict* packages are themselves 
compiled by DUB automatically when you run it on your project. 
They are configured to compile as static libraries. Since DUB 
knows your project depends on them, it hands them off to the 
compiler (which in turn passes them to the linker) for you.

You seem to be mixing some terminology up a bit. There's a 
difference between static/dynamic linking and static/dynamic 
loading. The two types of linking affect how the linker generates 
the final executable, whereas the latter two types of loading 
determine how a dynamic library is loaded at runtime.

When you link with a static library at compile time (static 
linking), the library's object code is a part of the executable. 
The linker combines it all into one package and it all gets 
loaded by the system in one go at runtime.

When you link with a dynamic library at compile time (dynamic 
linking), the linker will fix up your executable such that when 
the program is run, the system loader will notice the reference 
the linker left for the dynamic library, so it will also load the 
dynamic library into the executable's process space (static 
loading).

If you want to use a dynamic library without linking to it at 
compile time, then you have to load it manually at runtime 
(dynamic loading), which means you have to declare all of the 
library's functions as function pointers instead of using regular 
function declarations. Then, at runtime, you load the library 
into memory and then fetch the address of each function. 
Essentially, you're doing by hand what the linker and system 
loader would do for you if you had linked with the dynamic 
library at compile time.

When using any C library from D, you have to declare all of the 
functions from that library in a format D understands. That's 
your binding. If you choose to use regular function declarations, 
then you have a static binding. You can use a static binding with 
both static and dynamic libraries, but they have to be passed to 
the linker at compile time. To be clear, a static binding does 
not restrict you to using only static libraries. It gives you a 
choice, but you will always have a compile time dependency.

A dynamic binding is one in which the functions are all declared 
as pointers so that a dynamic library can be loaded manually at 
runtime. There is no link time dependency. As such, it can *only* 
be used with dynamic libraries.