0

Now I am writing a program to call a web service. I write testMain.c. The others are generated by wsdl2h and soapcpp2.

My compiling command is like this:

 gcc -Wall -g -c -L. soapC.c soapClient.c stdsoap2.c testMain.c
 gcc -o testMain -L/usr/lib -lgsoap -lgsoapck -lgsoapssl soapC.o soapClient.o stdsoap2.o testMain.o

And I get these errors. Please help me. 

stdsoap2.o: In function `soap_print_fault':
/test/stdsoap2.c:16279: undefined reference to `soap_check_faultsubcode'
/test/stdsoap2.c:16281: undefined reference to `soap_check_faultdetail'
stdsoap2.o: In function `soap_sprint_fault':
/test/stdsoap2.c:16341: undefined reference to `soap_check_faultdetail'
collect2: ld returned 1 exit status
Fei Xue
  • 1,995
  • 5
  • 19
  • 29

4 Answers4

1

Recent versions of GCC/ld/the GNU toolchain require that the object and library files be specified in a certain order, so that symbols can be found by the linker in the same order they depend on each other. This means that libraries should go to the end of the command line; your second line (when you're linking) should be

gcc -o testMain -L/usr/lib soapC.o soapClient.o stdsoap2.o testMain.o -lgsoap -lgsoapck -lgsoapssl

instead.

  • i use your command , it still get those errors. It seems that there is no file can supply `soap_check_fault*` functions . – Fei Xue Dec 31 '12 at 07:58
  • @ccsnailpp Try playing around with the order of the objects files as well then. –  Dec 31 '12 at 08:24
  • @ccsnailpp then you're missing something else as well. –  Jan 01 '13 at 01:07
0

I search the web, and found a post which is very similar with my problem. I use this solution and have solved the problem. http://www.mail-archive.com/gsoap@yahoogroups.com/msg01022.html

Fei Xue
  • 1,995
  • 5
  • 19
  • 29
0

You should not need to link stdsoap2.o to your project because it's already included in libgsoap (given through the gcc linker option -lgsoap). Try to exclude stdsoap2.c from your project. From the gSOAP FAQ:

I get a link error with gcc/g++ (GNU GCC). What should I do? For C apps: use soapcpp2 option -c to generate C code, use only the package's .c files, link with libgsoap.a (-lgsoap) or use the lib's source stdsoap2.c (and dom.c when applicable).

Christian Ammer
  • 7,464
  • 6
  • 51
  • 108
0

I had the same problem with gsoap-2.8.16 compiled from source. (That version was shipped with CentOS 6.)

First I checked for a missing library. According to nm used on all static libraries provided by gsoap-2.8.16:

for X in /usr/local/lib/libgsoap*.a ; do echo $X; nm $X | grep soap_check_faultdetail; done`

it turned out that none of the libraries provided the missing symbols.

A brief look at the source code revealed that the expected return type of both methods soap_check_faultdetail and soap_check_faultsubcode was const char*, and that these were used to generate error messages.

It looked to me as if these are meant to be callbacks that the client must provide. Maybe their implementation is WSDL-dependent and would be supplied by the gsoap code generation utilities - that I don't know, see the answer from @ChristianAmmer above or below.

Anyway, since I knew the symbols were nowhere supplied, and that null-terminated strings were probably acceptable here, I just supplied my own no-op implementation:

// gsoap-missing-symbols.cpp
extern "C" {
const char* soap_check_faultdetail() { return 0; }
const char* soap_check_faultsubcode() { return 0; }
}

This is a brute-force solution. If you follow this solution, you should maybe check for linker warnings in the future; maybe some mechanism (eg. from the gsoap code generator) will supply conflicting implementations later during development.

For later versions of gsoap, I believe these symbols are no longer used and can be dropped (or renamed), see soap_check_faultX in https://www.genivia.com/changelog.html.

Christian Fuchs
  • 430
  • 3
  • 9