Re: Compiling and linking libraries
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.
Re: Compiling and linking libraries
On Wednesday, 16 November 2016 at 16:05:06 UTC, Mike Parker wrote: On Wednesday, 16 November 2016 at 14:59:40 UTC, Edwin van Leeuwen wrote: Thank you for this! Great information. So dub dynamically "add" code from the dll into the source code at runtime? Also will I ever need to learn how to use static libraries and is there a reason to?
Re: Compiling and linking libraries
On Wednesday, 16 November 2016 at 14:59:40 UTC, Edwin van Leeuwen
wrote:
If you are happy to use dub I would just add the GL library as
a dependency to my dub.json file. Then if you call dub it will
download and compile the necessary file.
Example dub.json file:
```
{
"name": "myWindow",
"authors": [
"Darren"
],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Darren",
"dependencies": {
"derelict-gl3": "~>2.0.0-alpha.2"
}
}
```
You'll also want the derelict-glfw3 binding so that you can
create the window and OpenGL context in the same way as the
learnopengl.com tutorials. Moreover, as the maintainer of
Derelict, I advise against using the 'alpha' versions of the
Derelict libraries for now given that this is a learning
exercise. Your dependencies should look more like this:
"dependencies": {
"derelict-gl3": "~>1.0.19"
"derelict-glfw3" : "~>3.1.1"
}
You don't need to worry about CMake, as DUB fills that role (and
more). You also don't need to worry about GLEW, which is strictly
a C and C++ thing. DerelictGL3 will perform the same function.
Just make sure you have the latest GLFW DLL in your project
directory on Windows, or have installed it in the system
directories on Mac or Linux. On Windows, you can save yourself
some trouble by structuring your tutorial directories something
like this:
- learnogl
- bin
-- glfw3.dll
-- HelloWindow
--- dub.json
-- HelloTriangle
--- dub.json
Then, somewhere in each dub.json, add the following line:
"targetPath": "../bin"
Make sure each dub.json has a different "name". On Mac or Linux,
the GLFW shared library will be in on of the system directories
after you install it, so you don't need to worry about it.
Here are some major points you need to be aware of that will
differ from the tutorial:
* You don't need to link with any libraries. All of the Derelict
packages are dynamic bindings by default [1], so there are no
link-time dependencies. That means the share libraries (DLLs)
need to be loaded manually. Before you call any OpenGL or GLFW
functions, you need the following two lines (preferably at the
top of your main function to play it safe):
DerelictGL3.load();
DerelictGLFW3.load();
This will load the libraries. For GLFW, that's all you need to
use it. For OpenGL, this will only load the the functions up to
1.1. In order to load the rest, you first need to create a
context. In the learnopengl.com tutorial called 'Hello Window',
completely ignore the following:
glewExperimental = GL_TRUE;
if (glewInit() != GLEW_OK)
{
std::cout << "Failed to initialize GLEW" << std::endl;
return -1;
}
Remember, you don't need GLEW. Instead, replace it with this:
DerelictGL3.reload();
Make sure it's after the call to glfwMakeContextCurrent. With
that, you'll be able to mostly use the same C code the tutorial
uses in your D programs. There are a small number of subtle
differences that will cause the D compiler to complain (mostly
about implicit conversions), but I won't list them here because
that will just confuse you. When you encounter them, if it isn't
obvious what's going on, you can always come back here and ask
for help.
[1] http://derelictorg.github.io/bindings/
Re: Compiling and linking libraries
On Wednesday, 16 November 2016 at 14:27:41 UTC, Darren wrote:
Hey all,
This is a very beginner problem, but not one I know how to do
on my own. Could anyone give a step-by-step guide on how to
compile libraries, and then use them in my project with DUB?
If you are happy to use dub I would just add the GL library as a
dependency to my dub.json file. Then if you call dub it will
download and compile the necessary file.
Example dub.json file:
```
{
"name": "myWindow",
"authors": [
"Darren"
],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Darren",
"dependencies": {
"derelict-gl3": "~>2.0.0-alpha.2"
}
}
```
This will build the necessary library into your library though,
so it is not the same as using a static library.
Also see the "Creating an own project" section on
https://code.dlang.org/getting_started
Compiling and linking libraries
Hey all, This is a very beginner problem, but not one I know how to do on my own. Could anyone give a step-by-step guide on how to compile libraries, and then use them in my project with DUB? For example, I've been using this guide for graphics: http://www.learnopengl.com/#!Getting-started/Creating-a-window In this, it says to use CMake, configure for an IDE, etc. But I am not sure how to use this with D, and I'm not using an IDE (only a text editor and dub). I've gotten by with just copy-pasting pre-compiled binaries into my project folder, but I should learn how to use static libraries (I hope I'm using the right terminology). Thanks!
