I have a static library placed in the same directory where the project is. I go to Projects->Build Options, then click on the Linker tab, add the library, and when it asks me if I want to use the relative path, I choose "yes".
I have no problems compiling at all, but when the linker runs, it complains it can't find the library. The only way I found to solve this is by telling Code::Blocks to to keep the path absolute, which is sort of annoying because I have to mirror the complete directory structure starting from root (or change the project properties) each time I want to compile it in another computer. (Something I have to do often, by the way)
Does anybody know what I might be failing to do?
Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.
did you go to "Settings->Compiler and Debugger->Global Compiler Settings->Other" and check one/both of the boxes for explicitly adding the current directory to search dirs?
[edit]
Quote from: mandrav on August 01, 2006, 08:54:43 AM
Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.
This isn't the default setting yet?
[/edit]
I've had the same problem, and i solved it this way: enter the library full name (eg libsomething.a or something.lib) and then prepend it with these two chars: .\ so the resulting filename will be .\libsomething.a or .\something.lib.
To answer everyone at once....
Quote from: mandrav on August 01, 2006, 08:54:43 AM
Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.
-------------- Build: Debug in LaserControl ---------------
mingw32-g++.exe -Wall -g -IC:\MinGW\include -c textwriter.cpp -o obj\Debug\textwriter.o
mingw32-g++.exe -LC:\MinGW\lib -o bin\Debug\LaserControl.exe obj\Debug\bezier.o obj\Debug\bufferednode.o obj\Debug\clipper.o obj\Debug\commandbuffer.o obj\Debug\main.o obj\Debug\normalizeintensity.o obj\Debug\pipelinenode.o obj\Debug\sc2000.o obj\Debug\textwriter.o -lfreetype.a
C:\Developement\MinGW\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe: cannot find -lfreetype.a
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
1 errors, 0 warnings
Quote from: kidmosey on August 01, 2006, 01:17:41 PM
did you go to "Settings->Compiler and Debugger->Global Compiler Settings->Other" and check one/both of the boxes for explicitly adding the current directory to search dirs?
That's for the compiler, not the linker, but thanks :)
Quote from: kkez on August 01, 2006, 10:45:36 PM
I've had the same problem, and i solved it this way: enter the library full name (eg libsomething.a or something.lib) and then prepend it with these two chars: .\ so the resulting filename will be .\libsomething.a or .\something.lib.
That did it!!. Thanks a lot!
./ may also work and this would make the solution viable for people using Linux builds
Quote from: Edis Krad on August 02, 2006, 04:08:12 AM
That's for the compiler, not the linker, but thanks :)
oops, sorry! :oops:
So, can I say it is a bug of Code::Blocks ?
Quote from: kidmosey on August 02, 2006, 07:36:47 AM
Quote from: Edis Krad on August 02, 2006, 04:08:12 AM
That's for the compiler, not the linker, but thanks :)
oops, sorry! :oops:
You don't beed to be sorry, because you were right. This setting is for the compiler *and* the linker process. As it shows all commands issued to the compiler/linker executable in detail.
With regards, Morten.
Quote from: kingfox on October 22, 2006, 11:45:15 AM
So, can I say it is a bug of Code::Blocks ?
I wouldn't say so. You could also include the path to the library in the linker options. Then you don't have to put the .\somelib.a. If the linker cannot find a library then the path is usually just missing. But I wonder if you did that alrteady and I'm missing something...?!
With regards, Morten.
Quote from: MortenMacFly on October 22, 2006, 01:31:36 PM
Quote from: kidmosey on August 02, 2006, 07:36:47 AM
Quote from: Edis Krad on August 02, 2006, 04:08:12 AM
That's for the compiler, not the linker, but thanks :)
oops, sorry! :oops:
You don't beed to be sorry, because you were right. This setting is for the compiler *and* the linker process. As it shows all commands issued to the compiler/linker executable in detail.
With regards, Morten.
lol, at first I thought the same :lol:, but he wasn't talking about the Full build log setting.
Quote from: MortenMacFly on October 22, 2006, 01:34:56 PM
I wouldn't say so. You could also include the path to the library in the linker options.
Well. Thanks for your explaination. But I think it's better that C::B can treat the project directory as the default search path of include files and libraries, thus if the items in "link libraries" list have not ".\", C::B will know these kind of items are in project directory.
Quote from: kingfox on October 23, 2006, 02:02:17 PM
But I think it's better that C::B can treat the project directory as the default search path of include files and libraries, thus if the items in "link libraries" list have not ".\", C::B will know these kind of items are in project directory.
I don't believe an IDE that thinks too much is good. Actually this is a wrong project setup. Anyway, for guys like you (not offending here) there is an option - see the image attached.
With regards, Morten.
Ps.: If you are getting deeper into the usage of C::B you will realise that a project can consist of 1..n targets which itself could have a completely different top-level path. So such automation wouldn't be helpful in all cases.
[attachment deleted by admin]
Quote from: MortenMacFly on October 23, 2006, 02:19:32 PM
Anyway, for guys like you (not offending here) there is an option - see the image attached.
With regards, Morten.
Thank you very much. May I think these two options can add the project's top directory and current compiled file's path into compiler and link path automatically ?
Now I have a project that use a library file named gccdll.a. This library file is in the project's top directory. I add gccdll.a into the "link libraries" list. pls see the first attachment. When I build this project, compiler said:
mingw32-g++.exe -L..\gccdll -LD:\CodeBlocks\lib -o .\usedll.exe obj\Debug\main.o -lgccdll.a -lbccppdllvc.a
D:\CodeBlocks\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe: cannot find -lgccdll.a
collect2: ld returned 1 exit status
I have already enabled the two "Explicitely Add ..." options in "Global Compiler Settings" dialog.
Then, I insert ".\" before every item in "link libraries" list shown as the second attachment image, above problem disappeared.
Maybe my idea about these two options is wrong ?
Quote from: MortenMacFly on October 23, 2006, 02:19:32 PM
Ps.: If you are getting deeper into the usage of C::B you will realise that a project can consist of 1..n targets which itself could have a completely different top-level path. So such automation wouldn't be helpful in all cases.
Yes, you are right. Thanks.
[attachment deleted by admin]
QuoteMay I think these two options can add the project's top directory and current compiled file's path into compiler and link path automatically ?
Adds the dirs to the compiler's search paths, not the linker's. Does it make sense to add them to the linker's too?
Quote from: mandrav on October 24, 2006, 03:50:15 PM
QuoteMay I think these two options can add the project's top directory and current compiled file's path into compiler and link path automatically ?
Adds the dirs to the compiler's search paths, not the linker's. Does it make sense to add them to the linker's too?
Yes, I think it's useful for me. But no matter even if it doesn't add them to the linker's. May be I didn't express my idea clearly. Actually, I want to know if I don't specify the path to every item (these items are in current project's directory) in "link libraires" listbox, where will C::B look up this item? In others word, where will C::B think these no-path-specified item should be?
When I add the ".\", the command line will be "mingw32-g++.exe -L..\gccdll -LD:\CodeBlocks\lib -o .\usedll.exe obj\Debug\main.o .\gccdll.a" (gccdll.a is the item in the "link libraries" listbox and this file is in current project's directory). And when I remove the ".\" of the items in "link libraries" list, the command line will be "mingw32-g++.exe -L..\gccdll -LD:\CodeBlocks\lib -o .\usedll.exe obj\Debug\main.o -lgccdll.a". Why C::B add a "-l" before "gccdll.a" ?