Your project contains 5 source files, which each has to be successfully compiled, and then all
need linked together, along with some axis2c DLLs, to build your program.
Let's look at your build log.
There is a compile command for each of the 5 source files:
mingw32-gcc.exe -Wall -g -IC:Toolsaxis2cinclude -IE:devCodeBlocksMinGW -c E:devcMathadb_addOperatorResponse.c -o objDebugadb_addOperatorResponse.o
...
mingw32-gcc.exe -Wall -g -IC:Toolsaxis2cinclude -IE:devCodeBlocksMinGW -c E:devcMathaxis2_extension_mapper.c -o objDebugaxis2_extension_mapper.o
...
mingw32-gcc.exe -Wall -g -IC:Toolsaxis2cinclude -IE:devCodeBlocksMinGW -c E:devcMathaxis2_stub_MathService.c -o objDebugaxis2_stub_MathService.o
...
mingw32-gcc.exe -Wall -g -IC:Toolsaxis2cinclude -IE:devCodeBlocksMinGW -c E:devcMathmain.c -o objDebugmain.o
...
mingw32-gcc.exe -Wall -g -IC:Toolsaxis2cinclude -IE:devCodeBlocksMinGW -c E:devcMathadb_addOperator.c -o objDebugadb_addOperator.o
...
and then there is a link command:
mingw32-g++.exe -LC:Toolsaxis2cinclude -LE:devCodeBlocksMinGWlib -o binDebugMath.exe objDebugadb_addOperatorResponse.o objDebugaxis2_extension_mapper.o objDebugaxis2_stub_MathService.o objDebugmain.o objDebugadb_addOperator.o -laxiom -laxutil -laxis2_engine -laxis2_parser
...
Copy/paste these commands out somewhere where you can see them from end to end.
In all of the places where I have put '...', the compiler or linker has emitted some complaint about your program.
All of the diagnostics emitted by the 5 compile commands are warnings. Whatever is not right, it doesn't actually stop the compiler from compiling the source
file (.c) into an object file (.o). If there had been any compilation errors in any .c file, then the compiler would not have been able to create the .o file,
and the build would have stopped without attempting to link the program, because linking it when some object files are missing would be futile.
This does not mean you don't have to bother about the compiler warnings. They might be warnings about possible bugs in your program, and some of them are.
So you'll need to fix them.
The link command has failed. You have no program, which is your top problem.
In order to make sense of compiler and linker diagnostics, and be able to fix them yourself, you need to understand what the compiler and linker commands mean.
We can see that the toolchain Code::Blocks is driving for you is the MinGW project's 32-bit Windows port of GCC (The GNU Compiler Collection).
GCC is the daddy of C/C++ programming toolchains: it's supported for every operating system and every processor; it's used in every application domain.
It's completely independent of any of the numerous IDEs that you can get to drive it, and all of those IDEs (Eclipse, Code::Blocks, KDevelop, CodeLite, Anjuta,
Dev-C++, etc.) come to you with the implicit assumption that you understand compiling and linking with GCC. At least, none of them can save you from having
to understand compiling and linking with GCC.
Before going any further then, the life-lesson of all this is going to be: Kick away your IDE for a while. Learn about building programs with GCC, itself.
Then it will be obvious how to do it with your IDE.
All of your compile commands are executed by mingw32-gcc.exe. That's the GCC tool-driver, in its C compiler "posture". If you look in the directory where it's installed,
maybe C:MinGWin, you'll see also programs gcc.exe, g++.exe, plus those two with the prefix mingw32-. All of these programs
are the GCC tool driver, in different "postures" adapted to different roles.
Your link command is executed by mingw32-g++.exe. That's the GCC tool-driver again, in its C++ linker "posture". It may seem puzzling that Code::Blocks
by default configures the C++ linker to link C programs. It does that because C++ linkage works for programs that are all C, all C++, or a mixture of the two.
But C linkage won't work for C++ programs.
Whatever "posture" is suggested by the name, the GCC tool driver figures out what needs to be done by inspecting the options on its commandline and the file extensions
of the files that are passed to it. So it tries to compile each of your .c source files as C because they are .c files.
If they were .cpp files then it would try to compile them as C++. Once it figures out what it do, it delegates the work to an appropriate specialized tool -
C compiler, C++ compiler, assembler, linker.
Here's what each of your compile commands means:
-Wall => Enable all warnings-g => Generate debugging information in the object file.-IC:Toolsaxis2cinclude => Search for non-standard header files in C:Toolsaxis2cinclude-IE:devCodeBlocksMinGW => Also search for non-standard header files in E:devCodeBlocksMinGW-c => Just compile; don't linkE:devcMathsome_filename.c => Compile this file.-o objDebugsome_filename.o => Output the object file objDebugsome_filename.o
And here's what your link command means:
-LC:Toolsaxis2cinclude => Search for non-standard libraries (.lib, .a, .dll) in C:Toolsaxis2cinclude-LE:devCodeBlocksMinGWlib => Also search for non-standard libraries in E:devCodeBlocksMinGWlib-o binDebugMath.exe => Output the executable binDebugMath.exeobjDebugadb_addOperatorResponse.o => Link this object fileobjDebugaxis2_extension_mapper.o => Also link this object fileobjDebugaxis2_stub_MathService.o => Also link this object fileobjDebugmain.o => Also link this object fileobjDebugadb_addOperator.o => Also link this object file-laxiom => Link the libary axiom.dll or failing that, axiom.lib or libaxiom.a, wherever it is first found in the specified linker
search directories (-L), or failing that in the linker's standard directories.-laxutil => Link the libary axutil.dll or failing that, axutil.lib or libaxutil.a, etc...-laxis2_engine => Link the libary axis2_engine.dll or failing that, axis2_engine.lib or libaxis2_engine.a, etc...-laxis2_parser => Link the libary axis2_parser.dll or failing that, axis2_parser.lib or libaaxis2_parser.a, etc...
You might wonder how the tool-driver knows that the link command is a link command, and not perhaps a C++ compile command?
It knows there is no compiling to do because none of the input files can be compiled. They are all object files (.o).
And it knows it is supposed to link them because it hasn't been told not to link them: the -c option is absent.
You linkage failed because:
e:/dev/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot find -laxiom
ld.exe is the linker itself: the specialized tool that the GCC tool driver invokes when there is linking to be done.
It can't find your axiom library in any of the linker search directories you specified (-L), nor, of course, in
any of the standard search directories.
Now that you understand the meaning of your link command, it will be easy for you to see what's wrong. The linker
search directories that you specified are:
C:Toolsaxis2cinclude
E:devCodeBlocksMinGWlib
and your axis2c libraries (axiom.dll etc) aren't in either of those places. C:Toolsaxis2cinclude
is the same place where you told the compiler to search for the axis2c header files: you have:
-IC:Toolsaxis2cinclude
So if that's where the axis2c header files are, then the libraries, I guess, are in C:Toolsaxis2clib. Have a look.
Assuming that's right, then in the C::B IDE you need to delete the wrong C:Toolsaxis2cinclude from Search directories -> Linker
for your project and replace it with the correct C:Toolsaxis2clib Leave C:Toolsaxis2cinclude in Search directories -> Compiler,
because that is correct.
Continued for OP's further issues
I believe that your axis2c libraries and header files originated from Apache's Axis2/C download page
from the archive axis2c-bin-1.6.0-win32.zip.
This release suffers from a bug in its header files that causes the linkage errors
you are seeing with the MinGW32 toolchain.
This bug does not affect Google's release of Axis2/C that I referred you to
in my first answer to this question. At that time you said that you were building with 64-bit MinGW, but it has since
become clear that you are building with 32-bit MinGW. In that case, you should download Google's 32-bit build Axis2/C
Unzip the archive with 7-Zip and rename the unzipped folder from axis2c to axis2c-x86-google, to make clear what it is, then copy it somewhere convenient
for your development. Let's say you put it at C:Toolsaxis2c-x86-google.
Then in the C::B IDE, in Search directories -> Compiler, change:
C:Toolsaxis2cinclude
to:
C:Toolsaxis2c-x86-googleincludeaxis2-1.6.0
and in Search directories -> Linker, change:
C:Toolsaxis2clib
to:
C:Toolsaxis2c-x86-googlelib
The library that is called axiom.dll in the Apache release is called axis2_axiom.dll in Google's release. Therefore
in your Linker settings -> Other linker options, change:
-laxiom
to:
-laxis2_axiom
Your program then links successfully (for me).
Continued again
Per your comments, the program now fails to load at runtime with the error:
The procedure entry point axis2_callback_create could not be located in the dynamic link library
This means the correct DLL providing axis2_callback_create is not found at runtime.
You say:
<block
