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.

[AndrewCot]

Guys, see Miguels's post #1 above as he explained what was needed to link a DLL and you guys are going in circles as you need to link to a .a file and if you do not have a .a file for the DLL then you need to get one!!!

[rascalito]

Hello!

Thanks for your reply!

I tried without the dll extension, it doesn't change.
I tried also many combinations, local path, absolute path, etc, since there are a few parameters that can have an influence
(and made a spreadsheet to be sure not to forget one combination).

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's probably what I will end doing. I'm surprised that such a simple task is so complicated with CodeBlocks. I'm working mostly
with embedded systems, (Texas instruments and more recently STM32) and when you need at lib, you just add it to the source tree
by browsing to its location, and you include the .h file in the code.
It was pretty much the same 25 years ago as a BeOS programmer. You add the dll (which was called "shared object", .so), you include
the h file and period! That's it.

Guys, see Miguels's post #1 above as he explained what was needed to link a DLL and you guys are going in circles as you need to link to
a .a file and if you do not have a .a file for the DLL then you need to get one!!!

So do you mean that CodeBlocks does not allow the use of DLLs?

R

[stahta01]

It means that Code::Blocks is not a magic wand!

If your compiler can not link to an DLL; using Code::Blocks will not make it work!

Can you answer the simple question was the DLL an C++ DLL or an C DLL?

If C++ DLL you must use an compatible C++ compiler to build and link the code.

If you post a full build log; when you try linking to the full path of the DLL I might be able to help you.

You likely have not tried linking to the DLL full path; but, since you have issues cutting and pasting the full log that is a guess on my part.

Edit: If you linked to the DLL using a full path I would expect to see something like the below in the log.

Code

-lC:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll

Edit2: Notice the "-l" in front of the DLL path.

Tim S.

[MortenMacFly]

Well, the easiest way is always to have the SDK for the (Kalman) lib that consists of both: The lib to links against and the runtime. DLL's are not guaranteed to be linkable. You can try but you may fail. It depends on the linker, not C::B. Also, in case of a DLL it could be way more issues, like wrong compiler flavour/architecture, wrong bit (32 vs. 64).

What you are trying to do can have many errors. So once again:
- Grab either the SDK and use the proper import lib
- Grab the source code of the Kalman.dll and compile it with the same compiler and create an import lib yourself.

But that is beyond the scope of this forum which is about C::B and not how to compile libs.

So please, keep this forum clean, remain in the scope of C::B related questions, otherwise this topic might get locked.

[tigerbeard]

I'm surprised that such a simple task is so complicated with CodeBlocks.

Once you solved your riddle, you will find that CB is very easy to use with DLLs/SOs. I am using SO's all the time and its just adding a path and a single name in CB,
As I did a few year ago, you might be surprised about the technical details of DLLs/SO's. Although DLLs and SOs are basically the same they follow different rules in Windows and Linux. They must to handle multiple versions on the same lib on system level, there are major differences between DLLs in C and C++ (keyword name mangling) and the fact that C++ DLLs only work if they were done with the same compiler as stahta01 wrote and more. Each OS creates a set of rules you must obey. On a microcontroller much of that is not an issue, making things a lot easier.
When I started with Visual Studio I was totally ignorant of all of this. I could copy & paste DLL code but I was a script kiddie rather than a programmer beacause I did not really understand what I was doing. From your posts I would guess you are not aware of any of those complexities as well. I am not implying you are not a good programmer (as I was), but you might have some things to catch up on DLLs.

So do you mean that CodeBlocks does not allow the use of DLLs?

Of course not, why should it? The use of DLLs in computer programming is so extraordinary rare that over 20 years of CB development you are the first user ever even mentioning that. Maybe you should consider filing a feature request for it. (irony off)
There was a Mercedes Benz S-Class driver asking after a test drive why the vehicle of the current Rallye motorsport world champion was so badly designed that you could not do a controlled turn with it? I wonder does  this question tell more about the vehicle or about the questioner?

Seriously, I can see you are frustrated.
Please allow me to point out a key item about CB: Its an open system. It allows you to use any compiler on any of the major OS including Arm compiler and MS visual studio's compiler. However, this flexibility and openess comes with a price: I does not shield you from technical complexiities as other IDEs do. There is a chance that if you do not understand what you are doing, you will fail. Embedded dev environments, VisualStudio and probable also Apple dev environments are tight and closed. They can be, because there is only only one way of doing things and the tools know all the fixed parameters and can do things for you.
It possible to extend CB to do the same, e.g. a DLL creation wizard for Windows, but you would need one for each combination of compiler and OS. Yet nobody thought such a thing was worthwhile, because knowing the basics and using the CB core facilities is the better option in the long run.
What CB is lacking though and what would help people in your situation is easyly accessible documentation like an help with How-Tos and examples or tutorials. But I am sure also in your case once you solved the issue like all people before you you will not gather enough motivation to sit down and write up a documentation like that. And once you have mastered the skills to use CB as a efficient tool you will lack the motiviation for it. Welcome to the viscious circle of open source. 

That's probably what I will end doing.

I am sorry I can not help you further on windows. Sitting in front of your terminal with the lib, the full log output and dev tools I m sure its easy to solve. However, I am sure what you say is the best way forward.

To get a feel for what is behind DLLs I can recommend David A. Wheelers paper "Program Library HOWTO" from May 15, 2010. I am sure google will find it. Although its Linux also Win users cross reading the 25 pgs should get a good feel why DLLs are more than they seem on the first glance. Win has the same issues, just different solutions. After reading you might see why here we fail to give you just the right cue.