Using DLLs with CodeBlocks

[rascalito]

Hello!

I'm a new user of CodeBlocks.
I have installed it an I'm using mingw64. Basically a hello world-ish program works,
debugger included.
Now I need to use a 3rd party DLL with some source code provided by the 3rd party.
Let's assume the dll is called my_dll and implements a function that I'll call "my_function"
(let's be creative!!). I have included my_dll.h.

The problem is that it doesn't compile or link. I get that kind of message:
undefined reference to __imp_my_function

Can anybody explain me how to use a DLL in CodeBlocks?

Thanks for any hint.

R.

[Miguel Gimenez]

The DLL contains C or C++ code?.

In the former case, you can link with the .a file (if you have it) or directly with the DLL (goto Project options -> Linker settings and put my_dll.a on the left listbox or my_dll.dll on the right.

In the latter case you are doomed (except if the DLL was created with the same MINGW64 and options).

If you have more problems post a full rebuild log.

[rascalito]

Hello!

Thanks for your reply!
No, I have only a .dll file.

By the way, some more info:
I'm using CodeBlocks 20.03, configured with MinGW64
    -> By the way, when I set the compiler, there was no xxx64, but only xxx32 options, for example
     c compiler: x86_64-w64-mingw32-gcc.exe // Why is it mingw32 and not 64???

goto Project options -> Linker settings and put my_dll.a on the left listbox or my_dll.dll on the right.

Ok, let's be accurate, I'm an absolute beginner with CodeBlocks...
In this cersion, I don't have a Project options menu. I have a Project top menu, and under this project
    menu, I have "Build options" and  "properties".

I have opened Project -> Build options which sounds more correlated to what you suggested. Is this right?
In the config window -> Lineker settings tab,  I have indeed 2 columns. I can put something on the left by
browsing to that file, but on the right column, I have to key in what I want to add (my_dll.dll). Does it
correspond to what's needed?

After keying in, I retried to compile everything (Rebuild workspace), and apparently things progressed
since all the undefined reference to __imp_my_function disappeared.

But now it says: error: ld returned 5 exit status.
Nothing more. I don't know what the 5 exit status mean. Is there a path problem? I tried the full path,
it doesn't help.

Any hint?

Thanks!

R

[Miguel Gimenez]

Quoting myself...

If you have more problems post a full rebuild log

https://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28general%29#Q:_How_do_I_report_a_compilation_problem_on_the_forums.3F

[rascalito]

Hello!

Sorry, I didn't notice that advice. I have checked the page, but it sarts with:
"Try building the project from command line. "

That's certainly a good idea, but it would be good to know how I rebuild form the command line.
Do I open a DOS window, go to the project location and run a make of some kind?

NB: I tried to google "codeblocks how to compile from the command line".

Thanks,

R

[Miguel Gimenez]

Forget that line and go to the part where full log is enabled.

[tigerbeard]

(let's be creative!!). I have included my_dll.h.

The problem is that it doesn't compile or link. I get that kind of message:
undefined reference to __imp_my_function

Can anybody explain me how to use a DLL in CodeBlocks?

Welcome to using C::B it requires a bit of getting used to but once you mastered that I am sure you will love it.

I am getting this message when i forget to include the library file itself in the build options. I am getting this message a lot as I usually forget to add the libs to the build options lib page.
The message is not a CB issue, since you would get it as well when you do not include the lib on the command line.

If you are new here a few general hints (which can not replace learning ftrom trial and error of course).
* learn the Project/Build options. This is the main dialog you will be using. Sadly there is not tool button for it. You find it in the menu Projects/BuildOptions... It takes a while to figure it all out.
** The dialog shows a tree with your build project on top and each build targets (Delete, Release etc) below. It took me some time to learn that everything I enter in the topmost tree item is valid for all items. Saves a lot of typing.
** for each project you must chech: compiler, link, Search directories. The others are optional.
** the link section is where you enter the libs. Here you must learn how to enter the name which is different between linux and windows. You can leave away the ending (.dll) for example. Generally you just add the name here. The paths to all libs must be in the search path pages. Make sure they are correct. Then the error you got should go away.
* The BuildLog and BuildMessage panes are your best friends  (in the lower message window - F2). Most VisualStudio users never had to do anything with the command line. Also CB kind of makes that transparent for you. But its really helpful to know about it. When you start build the BuildLog will open (if not hiffen with F2) and every cpp file in your project causes a command line output to the compiler, e.g. the mingw compiler you defind in the compiler setup. You see all command line parameters, e.g. the used libs and include paths. Since this is all in one line, the lines get very long and look a but cryptic. But they are quite simple to understand because there is only 3-4 different thing repeating all the time. So if you get a complie or linker error you do not understand, first thing you should to is to check one of the command lines in the BuildLog. All libs are listed for each command (e.g. -lGL for the OpenGL lib in Linux, similar in windows) and each search path is listed (-LC:/whatever). Its mutch easier to spot an error or a missing library there than in the many tabs in the BuildOption dialog  - but essentially all stuff you entered in the build options is for creating those lines.
* The BuildMessage you get after the compilation is only a summary of the BuildLog. If a certain thing is strange, often the much longer info and the compile command before helps you to find out what the problem might be.

[rascalito]

Hello!

Thanks a lot for the detailed reply. I will try that tomorrow (Monday morning).
Right now, it's beer time.

Thanks again!

R

[rascalito]

Hello!

Ok, it took longer than foreseen to find time to try it, but I did it. I checked the documents above (thanks Miguel)

I used the beginning of the template to give as many details as possible. As It doesn't even compile, I skipped
the description of runtime errors at the end.

--------------------
I am running Code::Blocks version 20.03 on Windows10
The compiler I use is MinGW 64
version: how do I know. Probably the latest one since I installed it last saturday.

I want to use an existing DLL I made earlier, called kalman_lib
- I have written a code that uses that DLL
- I have included the dll h file in my c code (#include "kalman_lib.h")
- I have opened Project -> build options
- In Linker Settings, I have added kalman_lib.dll by browsing from the add button to
   the library file. Apparently it's stored correctly in the left side space.
        As I was asked if I keep the local path, I tried both without any difference.
- I left "default" for linker executable.
- I first created a hello world-ish project (console application) with my future project
   name, and which prints hello on the terminal. Compiled and executed. It works.
- I have added the dll I want to use, in the same folder as my main.cpp code.
        I have changed the code in main by the real code, that uses the dll.
   As the compiler seems to find the source code, I guess it should find the library
        which is in the same folder. And beside this, it's also set in the project settings above.

When setting build options as suggested in the link above to save build log and
always output the full command line, I get an HTML file as follows:
--------------------
Build started on: 12-04-2022 at 20:43.58
Build ended  on:  12-04-2022 at 20:44.00
-------------- Build: Debug in Kalman (compiler: GNU GCC Compiler)---------------
x86_64-w64-mingw32-g++.exe -Wall -fexceptions -g -I..\Kalman -c C:\Users\Rascalito\Develop\CodeBlocks\Kalman\main.cpp -o obj\Debug\main.o
x86_64-w64-mingw32-g++.exe  -o bin\Debug\Kalman.exe obj\Debug\main.o   C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll
collect2.exe: error: ld returned 5 exit status
Process terminated with status 1 (0 minute(s), 2 second(s))
1 error(s), 0 warning(s) (0 minute(s), 2 second(s))
--------------------
By the way how should I use the report? It's an HTML file, but if I post it in a code window, of course it shows the code.
I had to replace html to BBCode, which is not what I would call efficient.

Thanks,

R.

[tigerbeard]

- In Linker Settings, I have added kalman_lib.dll by browsing from the add button to
   the library file. Apparently it's stored correctly in the left side space.
        As I was asked if I keep the local path, I tried both without any difference.

I think the normal way is to add in the linker tabs the DLL filename only. No path. Then add the linker path to the search directory tab. Maybe thats is the resone for your weird linker output (see below).

x86_64-w64-mingw32-g++.exe -Wall -fexceptions -g -I..\Kalman -c C:\Users\Rascalito\Develop\CodeBlocks\Kalman\main.cpp -o obj\Debug\main.o
x86_64-w64-mingw32-g++.exe  -o bin\Debug\Kalman.exe obj\Debug\main.o   C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll
collect2.exe: error: ld returned 5 exit status

Thesse two lines are the key lines to check. Anything you set in CB somehwere is only used to produce these two commands.

Code

x86_64-w64-mingw32-g++.exe -Wall -fexceptions -g -I..\Kalman -c C:\Users\Rascalito\Develop\CodeBlocks\Kalman\main.cpp -o obj\Debug\main.o

This calls the compiler compiling your source code. When you copy this line, go into a terminal into your project folder it should compile as well. That should be fine

Code

x86_64-w64-mingw32-g++.exe  -o bin\Debug\Kalman.exe obj\Debug\main.o   C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll C:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll

This calls the linker. This line causes your error. This should not list your DLL twice and it should list it with a prefix (-l on Linux, I think the syntax in windows was the same, but I can not remember right now). Typically a linker line should more look like that

Code

x86_64-w64-mingw32-g++.exe  -LC:\Users\Rascalito\Develop\CodeBlocks\Kalman -o bin\Debug\Kalman.exe obj\Debug\main.o   -lkalman_lib.dll

(seems the code formating eats the '_' char) To figure out how the correc way is, again go to your projet folder in a termina and type there linker command there. Once you got it running you will know how to enter the data into the build settings to yield the correct result on the command line.

[rascalito]

Hello!

Thanks for your detailed reply. I tried a few things:
1. The first line: I verified it compiles fine.
   Open a terminal (I use CygWin), and go to he development folder.
   Type the first line like this:

Code

x86_64-w64-mingw32-g++.exe -Wall -fexceptions -g -I ../Kalman -c main.cpp -o obj/Debug/main.o

and there was no error. NB: I have used local paths, not absolute, and it has no influence.

2. The second line (linker command)
I typed it using tab (autocompletion), which proves that the files and paths really exist.
x86[tab] -Wall -fexceptions -g -I ../MNF[tab] etc... so that I'm sure there is no spell miss.
The full command and PC output was:

Code

x86_64-w64-mingw32-g++.exe -o bin/Debug/Kalman.exe obj/Debug/main.o -l kalman_lib.dll
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lkalman_lib.dll: No such file or directory
collect2.exe: error: ld returned 1 exit status

So although the PC seems to "understand" where are the various components, ld still says it cannot find it.
I have tried to add "./" to the dll path (which is the current directory path). No change.

(seems the code formating eats the '_' char)

Where exactly should this "_" be?

Thanks,

R

[tigerbeard]

NB: I have used local paths, not absolute, and it has no influence.

No its your free choice. Personally I use local paths because it makes the project relocatable.

The full command and PC output was:

Code

x86_64-w64-mingw32-g++.exe -o bin/Debug/Kalman.exe obj/Debug/main.o -l kalman_lib.dll
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lkalman_lib.dll: No such file or directory
collect2.exe: error: ld returned 1 exit status

So although the PC seems to "understand" where are the various components, ld still says it cannot find it.

Perfect. Not because it does not work yet but you now have boiled down the problem to the root cause: understand you MinGW compiler/linker syntax for including a windows dll. Believe me or not, but learning this will save you countless hours of pain in searching compiler and linker errors. By just using google you can find examples for valid MinGw command lines others used before.
For example unter https://stackoverflow.com/questions/27421102/mingw-linking-to-a-dll-on-windows you can see simple example that puts down this

Code

g++  -o "Win32App.exe" -L"..\..\SK develop\SK91GigE-WIN\Lib" obj/winmain.o obj/callbacks.o obj/resource.o -s -lcomctl32 -Wl,--subsystem,windows -lSK91GigE_x64

If that does not work, you get a great tip on that page what other issue might be a cause. In your case I would suggest to find out what "-L" does and how you could add it to your code line.

Where exactly should this "_" be?

I meant the missing char in the libfilename in the formatted code. At least in my browser the code line read "-lkalman lib.dll" instead of "-lkalman_lib.dll". Just ignore it.

[rascalito]

Hello!

Thanks for you reply.
Usually what I understand best is a working example.
Apparently the original poster has a problem which is not the same as mine. His problem is
lib format not recognized, my problem is library not found.
I'm using MinGW 64, I'm using a 64 bit library, so I guess it should be fine.

understand you MinGW compiler/linker syntax for including a windows dll.

I'm ready to understand. I tried to add -L which is apparently an indication of the search
dir. -L "./". It doesn't work either.

If that does not work, you get a great tip on that page what other issue might be a cause.
In your case I would suggest to find out what "-L" does and how you could add it to your code line.

Might be nice to directly indicate which great tip.
I read the question and the answer, there is only one answer which says that the path is wrong.
In my case, I have all at the same place to keep it simple in a first run, except the subfolders
bin and obj.

R.

[tigerbeard]

Sorry my Windows is a but rusty.

I did say it was a working solution from which you could fine out what is wrong with your line.
I did not say it was the exact example for your situation. I am sure by googling you can find one, however, just takes a bit of time. I just took to first example I came across. That OP sample showed that there amy many very different causes. His cause was not a wrong CLI line.

Why did you not match the working example? You added the local path, thats good. But I would also try to include the lib the same way. I can not check that for you ( no win box available), so you have to test it yourself.

Code

  -lcomctl32     // not -lcomctrl32.DLL 

If that does not work as well I would try to get a small sample from the web were you create a DLL yourself and run a test program. That rules out pretty much any other potential factors. The samples usually are only a few lines. If that is working you have the correct syntax and can swap you DLL and see if then the issue comes back. I recall sometimes in Win I included a *.lib file for using a dll, but I might mix sth up.

[tigerbeard]

Sorry my Windows is a but rusty.

I did say it was a working solution from which you could fine out what is wrong with your line.
I did not say it was the exact example for your situation. I am sure by googling you can find one, however, just takes a bit of time. I just took to first example I came across. That OP sample showed that there amy many very different causes. His cause was not a wrong CLI line.

Why did you not match the working example? You added the local path, thats good. But I would also try to include the lib the same way. I can not check that for you ( no win box available), so you have to test it yourself.

Code

  -lcomctl32     // not -lcomctrl32.DLL 

If that does not work as well I would try to get a small sample from the web were you create a DLL yourself and run a test program. That rules out pretty much any other potential factors. The samples usually are only a few lines. If that is working you have the correct syntax and can swap you DLL and see if then the issue comes back. I recall sometimes in Win I included a *.lib file for using a dll, but I might mix sth up.

Update: I found an old note saying that in Windows you can not link a DLL to an exe directly but you need an export lib. If that is correct even a correct CLI line would give you errors, since you have to use a different version of your lib. In that case maybe a tutorial on Windows DLL might prove more useful. Its nothing to do with CodeBlocks, of course.