User forums > Help
Using DLLs with CodeBlocks
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
--- End code ---
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
--- End code ---
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.
--- Quote ---(seems the code formating eats the '_' char)
--- End quote ---
Where exactly should this "_" be?
Thanks,
R
tigerbeard:
--- Quote from: rascalito on April 13, 2022, 05:35:11 am ---NB: I have used local paths, not absolute, and it has no influence.
--- End quote ---
No its your free choice. Personally I use local paths because it makes the project relocatable.
--- Quote from: rascalito on April 13, 2022, 05:35:11 am ---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
--- End code ---
So although the PC seems to "understand" where are the various components, ld still says it cannot find it.
--- End quote ---
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
--- End code ---
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.
--- Quote from: rascalito on April 13, 2022, 05:35:11 am ---Where exactly should this "_" be?
--- End quote ---
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.
--- Quote ---understand you MinGW compiler/linker syntax for including a windows dll.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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
--- End code ---
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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version