Hi, On this one, I would like to add that both sscanf and strtol should be installed and detected when compiling.
If you use the autotools, adding: AC_CHECK_FUNCS([random gettimeofday ftime localtime_r timegm gmtime gmtime_r memset select socket strchr strerror strrchr strstr strtol strtoul strtoll strtoull strtold strtod strtof strtold_l strtod_l strtof_l sscanf sscanf_l sprintf_l wctomb mbtowc]) to configure.in , then running autoheaders ; automake; autoconf and rebuilding the package will make LONG64 working. otherwise, you have to define -DHAVE_STRTOL -DHAVE_SSCANF ... o the command line. The AC_CHECK_FUNS i the one taken from the configure.in file in gsoap sources. Hope this help people save some time :) --- In [EMAIL PROTECTED], "defaultuserbr" <[EMAIL PROTECTED]> wrote: We've run into a problem with a struct member that's of type LONG64. [snip] All seems good. It compiles with no diagnostics. However, when sending messages with this data type, we get the message: Validation Constraint Violation: data type mismatch in element <id> The build platform is Linux and gcc, with gSOAP 2.7.10. The same code runs fine on Windows. When we took stdsoap2.c out of the build, and linked against libgsoap.a, the problem went away. I fixed this myself, so I'll reply to document the solution. When comparing my old hand-made makefiles for the platform with the ones the guy creating the automake system did, I noticed that I had used -D__linux__ in compiling. Adding this to the compile took care of the problem. Brian -- http://www.debuntu.org Debuntu deb's repository
<<attachment: debuntubanner-small.png>>
