Codeblocks: installing a library

Installing a compiled library for MinGW under Code::Blocks with MinGW

• Prerequisites
• Method
  • Decompressing into a directory centralizing used external libraries
  • Integration into the Code::Blocks project: 2 steps
    • Indicate to the compiler where to find the .h files
    • Indicate to the linker where to find the library binaries
• Notes
  • .dll files
  • Relative or absolute paths
  • Do not copy the external library into the MinGW directories of Code::Blocks
  • Terminology

Prerequisites

You have a version of Code::Blocks running with the MinGW compiler and you have retrieved a binary of an external library that you want to use, which is also compiled for MinGW.

You need to know whether you have a 64-bit or 32-bit version of MinGW and use a library compiled for MinGW for the same architecture (64-bit or 32-bit).

If you have installed Code::Blocks with a version bundled with MinGW from this page, you have a 64-bit version, unless you downloaded a specific 32-bit version.

In the example that follows, we will use the libcurl library to illustrate the method to use, that is to say, as of the date these lines are written, and for the current stable version of libcurl, this:

https://curl.se/windows/dl-7.83.1/curl-7.83.1-win64-mingw.zip
(go see the latest version on https://curl.se/download.html or on https://curl.se/windows/)

This method can be used with Code::Blocks using MinGW, for any library compiled for MinGW.

What you download must contain the necessary

.h

files for the

#include

directives and

.a

files that contain the binaries, meaning the precompiled elements of the library, and possibly

.dll

files.

Method

Decompressing into a directory centralizing used external libraries

Unzip the archive containing the compiled library into a not too complicated directory, and with a name without spaces.

For example:

c:\libs\curl-7.83.1-win64-mingw\

Integration into the Code::Blocks project: 2 steps

In Code::Blocks, there are 2 things to do for a project to use an additional library:

Indicate to the compiler where to find the .h files

Indicating to the compiler where to find the

.h

files allows it not to generate errors when inserting the corresponding #include directives in the source code.

You do this in: Project - Build options... - Click on the root of the project (not on the Debug or Target entries, otherwise the settings will only apply to that target)

Tab "Search directories" - Add - navigate to the library directory that contains the .h files and select that directory.

For example, in the case of libcurl, this directory is

c:\libs\curl-7.83.1-win64-mingw\include

which contains "curl". As the documentation of the libcurl library indicates to do

#include <curl/curl.h>

, you need to select the parent directory of "curl" so that

curl.h

is accessible via the path

curl/curl.h

.

Indicate to the linker where to find the library binaries

Indicating to the linker where to find the library binaries allows it to generate the executable after compilation. For the MinGW environment, the library binaries are files with the

.a

extension.

You do this in: Project - Build options... - Click on the root of the project (not on the Debug or Target entries, otherwise the settings will only apply to that target, unless you use debug libraries for a given library, then it becomes useful to distinguish by targets)

Tab "Linker settings" - Add - navigate to the library directory that contains the

.a

files (for example, in the case of libcurl

c:\libs\curl-7.83.1-win64-mingw\lib

) and select the parts of the library you need for your project.

If you don't know, see the library documentation (or, if unsure, compile the project, check the error messages, and add the necessary parts, or broadly, add everything :-).

Notes

.dll files

Depending on how you set up your project (dynamic or static linking), you may need to copy

.dll

files into the executable's directory (or into the Windows PATH) for dynamic loading of the library to occur.

In the case of libcurl, the

.dll

files are contained in

c:\libs\curl-7.83.1-win64-mingw\bin

.

They should be added, for example, to the "Target" directory of the project containing the executable generated by the compilation (or somewhere in the PATH), and this is only necessary when compiling with dynamic linking and to run the executable outside of the development environment.

If you haven't done this, you will notice when running the executable (by double-clicking on the

.exe

file, that is): a message will alert you that such and such a

.dll

was not found.

Relative or absolute paths

When setting up Code::Blocks, after selecting a resource, you are asked "Keep this as a relative path?".

If you answer yes, this means that Code::Blocks will not keep the absolute path to the specified resource (for example "

c:\libs\curl-7.83.1-win64-mingw\lib\libcurl.a

"), but only the relative path relative to the project directory (like "

..\..\..\libs\curl-7.83.1-win64-mingw\lib\libcurl.a

").

It is useful to specify a relative path if the resources are accessible under the project directory, as the project will remain compilable on another machine with Code::Blocks, the resources being in the same location relative to the project directory, regardless of where the project is located on the new machine.

On the other hand, if the resources are elsewhere (it’s better to put them elsewhere, to group libraries in an identified location where different projects can find them, like

c:\libs

and avoid duplication), and you move the project, the references will be broken. In that case, you should specify absolute paths.

Do not copy the external library into the MinGW directories of Code::Blocks

This may work, and you may come across tutorials that tell you to do so.

However, I advise against doing this unless you want to:

• clutter your Code::Blocks installation
• have to reinstall all your libraries because you update Code::Blocks or MinGW, and the default directories of Code::Blocks or MinGW are deleted and recreated during this process
• not know where such a version of the library exists that only compiles with such source that you use
• not know how to update your libraries

Terminology

In the preceding lines, the term "library" has been used. The latter is an anglicism (from the term "library"), which is often used by programmers.

It should be said, in proper French, "bibliothèque", but we assumed that both terms are synonymous for our document :-)

Dal

First publication: 2013-01-29 10:56:41 by [Dal]
Cat.: Practical sheets - Programming - Languages - C Language
This document is (c) [Dal] 2013-2022