Author Topic: Relative path to libraries does not link [SOLVED]  (Read 22070 times)

Offline Edis Krad

  • Single posting newcomer
  • *
  • Posts: 6
Relative path to libraries does not link [SOLVED]
« on: August 01, 2006, 08:49:51 am »
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?
« Last Edit: August 02, 2006, 04:10:48 am by Edis Krad »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Relative path to libraries does not link
« Reply #1 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.
Be patient!
This bug will be fixed soon...

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Relative path to libraries does not link
« Reply #2 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?

[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]
« Last Edit: August 01, 2006, 01:23:45 pm by kidmosey »
3 years until google knows more than god.

Offline kkez

  • Almost regular
  • **
  • Posts: 153
    • WinapiZone
Re: Relative path to libraries does not link
« Reply #3 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.

Offline Edis Krad

  • Single posting newcomer
  • *
  • Posts: 6
Re: Relative path to libraries does not link
« Reply #4 on: August 02, 2006, 04:08:12 am »
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

  • Guest
Re: Relative path to libraries does not link [SOLVED]
« Reply #5 on: August 02, 2006, 04:14:32 am »
./ may also work and this would make the solution viable for people using Linux builds

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Relative path to libraries does not link
« Reply #6 on: August 02, 2006, 07:36:47 am »
That's for the compiler, not the linker, but thanks :)

oops, sorry!  :oops:
3 years until google knows more than god.

Offline kingfox

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Relative path to libraries does not link [SOLVED]
« Reply #7 on: October 22, 2006, 11:45:15 am »
So, can I say it is a bug of Code::Blocks ?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Relative path to libraries does not link
« Reply #8 on: October 22, 2006, 01:31:36 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Relative path to libraries does not link [SOLVED]
« Reply #9 on: October 22, 2006, 01:34:56 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

takeshimiya

  • Guest
Re: Relative path to libraries does not link
« Reply #10 on: October 22, 2006, 01:35:38 pm »
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.

Offline kingfox

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Relative path to libraries does not link [SOLVED]
« Reply #11 on: October 23, 2006, 02:02:17 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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Relative path to libraries does not link [SOLVED]
« Reply #12 on: October 23, 2006, 02:19:32 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]
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline kingfox

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Relative path to libraries does not link [SOLVED]
« Reply #13 on: October 24, 2006, 02:57:09 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 ?

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]
« Last Edit: October 24, 2006, 03:00:59 pm by kingfox »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Relative path to libraries does not link [SOLVED]
« Reply #14 on: October 24, 2006, 03:50:15 pm »
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 ?

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?
Be patient!
This bug will be fixed soon...