- 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.
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
x86_64-w64-mingw32-g++.exe -LC:\Users\Rascalito\Develop\CodeBlocks\Kalman -o bin\Debug\Kalman.exe obj\Debug\main.o -lkalman_lib.dll
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:
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:
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
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:
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
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
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
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.
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.
-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.
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.
-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.
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.
-lC:\Users\Rascalito\Develop\CodeBlocks\Kalman\kalman_lib.dll
Edit2: Notice the "-l" in front of the DLL path.
Tim S.