User forums > Using Code::Blocks
Relative path to libraries does not link [SOLVED]
takeshimiya:
--- 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 :)
--- End quote ---
oops, sorry! :oops:
--- End quote ---
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.
--- End quote ---
lol, at first I thought the same :lol:, but he wasn't talking about the Full build log setting.
kingfox:
--- 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.
--- End quote ---
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:
--- 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.
--- End quote ---
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:
--- 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.
--- End quote ---
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.
--- End quote ---
Yes, you are right. Thanks.
[attachment deleted by admin]
mandrav:
--- Quote ---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 ?
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version