Enable the full build log (in Settings->Compiler and debugger->[select your compiler]->Other) and post it here.
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
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?
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's for the compiler, not the linker, but thanks :)
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.That's for the compiler, not the linker, but thanks :)oops, sorry! :oops:
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...?!
lol, at first I thought the same :lol:, but he wasn't talking about the Full build log setting.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.That's for the compiler, not the linker, but thanks :)oops, sorry! :oops:
With regards, Morten.
I wouldn't say so. You could also include the path to the library in the linker options.
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.
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.Yes, you are right. Thanks.
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 ?
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?