OK, now i play the persona non grata and tell you that we need a build log to find the error. You have to understand that without build log we can not tell what you are doing and we can not tell you what is going on. Only by describing you let out information only a build log can tell.
All the file are in project root folder: C:\LibTest (LibTest is the C::B project).
Then add a "." in Project->Build options->Select your project on the left->Search paths->Compiler
and Project->Build options->Select your project on the left->Search paths->Linker
And the compiler will search in your project folder.
(WTF? Why I've to add it to search dir, isn't it obviously must be searched by default?)
That is your opinion. Mine is an other. For example in java it takes automatically some predefined files from some folder and i needed like 100h to find out why it always took the wrong file. It simply had an build in automatic search algorithm. This annoyed me like hell. Better the user has to tell where to search. So he always knows what is going on.
Also if you use different libraries for Debug and release they can not be in the project root folder. All in all it is complex, and codeblocks goes the non idiot proof way and lets the user decide what to do.
You can create a project template where the project folder is added by default: Create a your basic hello world project like you want it. Then File->Save as template. The next time you can use this as base with File->New->Project->User templates
Again: Codeblocks goes the way that a user can decide by itself how to do things...
Can't add LibTest.dll from Linker setting but choose All file to add it anyway, failed: can't find LibTest.dll!
What is the exact error? There you have to differentiate:
1) The compiler can not find the file per se? Fix the search path in the Project->Build->options->Select the project name on the left from the tree->Search direcotries->Linker
2) The compiler can find the file but can not read it (this error is not easy to find, because the compiler tells you only about undefined reference). To find this error you have to add the "-v" option to the linker settings in Project->Build options->Select the project name on the left->Linker settings->additional options. The rebuild and look at the build log. The compiler will then tell you that the provided .dll is not usable. To fix this you have to got the dllool way as you described.
But without build log it is difficult to investigate.
dlltool -z LibTest.def --export-all-symbol LibTest.dll
dlltool -d LibTest.def -l LibTest.a
Follow someone on this forum to add this .def file to linker, either by choose All file like as the dll or other linker option (also on this forum, not bookmarked so don't have the link and don't care to search again because too tired)
Failed: can't find LibTest.def!
Add the LibTest.a file to linker (accepted), expect anything to be right but again: failed, can't find LibTest.a!
About this, you have to know that this is a mingw thing. Nothing to do with codeblocks. Also it is a language c/c++ thing. You can not mix different compiler and languages and think this is easy to handle... Every language uses different name mangling, different file formats for libraries, different call conventions ecc...
I even try to add all the file to project itself but still not find LibTest!!!
WTF! Does this IDE blind or too stupid to see the file I wonder?
The IDE does not complain, the compiler complains...
I like DevC++ makefile based than your xml based, in my opion xml is evil, I'm plain text fan.
then go the makefile route:
Project->Properties->Project settings->This is a custom Makefile
Now codeblocks will ignore all things and use the Makefile you provide to generate the binary. Note: No compiler settings are used, you have to write everything in your makefile by hand. Codeblocsk simply calls
make -f Makefile TARGETNAME
nothing more, nothing less. You have to add the source files by hand to the Makefile. You can set up how codeblocks calls the makefile (for example don't add the target ecc..)
My sentence is not useless, there really problem of out-of-sync between your global project build option and it child Debug and Release, it's very easy to reproduce, you change search directory or liker setting of the global, the first time it sync-ed to the child, the second or third or *th time it doesn't, you have to go the each child and change again, very time consuming: like, you remove a dir from search dir to point to new dir, the child still keep old dir so compiler started errors.
I use codeblocks on a daily basis and never encountered this. Codeblocks uses basically this hierarchy to set paths and compiler options:
Global compiler settings->Project settings->Target settings
But you can change this behavior in Project->Build options->Select the target name in the left tree control->Compiler settings->policy:
Append target options to project options
is the default, but there are many more policies..
Generally you add the search directories only at project level. This propagates to target level. Normally you won't change the global compiler settings...
The only thing i know that does not get updated and what annoys me a lot is the back tick cache. So if you use something like this in your build options
´wx-config --libs´
You have to restart codeblocks if something changes...
Codeblocks has it bugs and its flaws and we try everyday to fix them if a user reports errors. But it is not a easy to use software and it does not intend to be. You are using a build system you have to learn, like make files or cmake. In addition you want to mix different compilers and languages, what adds complexity on top. This is not a codeblocks thing but a compiler thing.
You posted 3 messages in this forum (as far as i can see):
1) The obligatory "i am human"
2) The question for adding the borland compiler
3) This rant.
If you would have asked for help sooner and provide build logs we would be able to help you and keep the fustration level low...