www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compiling and linking libraries

reply Darren <darren.fielding hotmail.co.uk> writes:
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: 

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!
Nov 16 2016
parent reply Edwin van Leeuwen <edder tkwsping.nl> writes:
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
Nov 16 2016
parent reply Mike Parker <aldacron gmail.com> writes:
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/
Nov 16 2016
parent reply Darren <darren.fielding hotmail.co.uk> writes:
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?



 Nov 19 2016



  parent  Mike Parker <aldacron gmail.com>  writes:


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.



 Nov 20 2016