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.
