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