Relative path to libraries does not link [SOLVED]

[Edis Krad]

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?

[mandrav]

Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.

[kidmosey]

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]

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]

[kkez]

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.

[Edis Krad]

To answer everyone at once....

Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.

Code

-------------- 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

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 :)

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!

[Sastraxi]

./ may also work and this would make the solution viable for people using Linux builds

[kidmosey]

That's for the compiler, not the linker, but thanks

oops, sorry!  :oops:

[kingfox]

So, can I say it is a bug of Code::Blocks ?

[MortenMacFly]

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.

[MortenMacFly]

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.

[takeshimiya]

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.

[kingfox]

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.

[MortenMacFly]

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]

[kingfox]

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 ?

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]

[mandrav]

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 ?

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?

[kingfox]

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 ?

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" ?