I’ll vote up darkhelmet since gSoap would also be my recommendation. We’re mostly a Java shop but with some C++ bits and gSoap has been our preferred SOAP integration way. It is indeed more work than your typical Java stacks but it seems solid.
A quick Google turned up this for a toolkit. While I have never used it, it seems to be quite popular and solid. Not exactly a package, and not really rolling your own, but sort of in the middle.
We went with gSOAP rather than Axis to avoid having a dependency on both a JRE and Axis just for building a C++ project. It’s worked ok, which is good since the gSOAP code is horrible and makes it very daunting to fix any bugs in it.
A warning about gSOAP linking though: you can never use more than one WSDL in a single link object (executable, dll, shared object). This is because some of the generated WSDL-specific functions have general names (e.g. soap_getfault()).
Worse, with Unix ELF linking, these names will cause cross-linking between shared objects, so a FooService fault might be processed by the soap_getfault() for BarService, corrupting memory if the fault detail structures are different.
The workaround for that is to make sure that nothing gSOAP-related is exposed outside the SO they are linked into. This can be solved by giving gcc these definitions _both when linking the gSOAP library itself and linking your code:
#define SOAP_FMAC2 __attribute__ ((visibility ("hidden"))) #define SOAP_FMAC4 __attribute__ ((visibility ("hidden"))) #define SOAP_FMAC6 __attribute__ ((visibility ("hidden"))) #define SOAP_NMAC __attribute__ ((visibility ("hidden")))
I solved it by putting them into a header file and forcing gcc to include that before anything else with
A better way if you can take the effort might to change the default ELF visibility to hidden, and only export the symbols you want to (like dllimport/dllexport in VC).