Gsoap 2.8.17 undefined reference to 'soap_initialize' - c++

I'm new with gsoap and trying to build a multithreading server standalone, reading the problems with the ubuntu package with memory by default, I installed the last version 2.8.17. Reading some posts here I tried the example posted by jackson
gSOAP Multithreading
so ... I execute soapcpp2 -i -S calc.h
and then when I compile this, I get this message :
In function CalculatorService::reset()':
soapCalculatorService.cpp:(.text+0x24f): undefined reference tosoap_initialize'
I've been looking where this method is declared but no look, hope you can give me some ideas! . Thanks in advance.

I guess you forgot to link with -lgsoap++ that define soap_init (or soap_initialiaze) depending on the gSOAP version.
The command to compile and link command could be something like :
g++ calc.cpp soapCalculatorService.cpp soapC.cpp -l gsoap++

Related

Build errors in cpprest sdk (casablanca) on Ubuntu 16.04

While searching for an HTTP client C++ based library, I have decided to use the casablanca -- so I needed to build it.
I'm running on Ubuntu 16.04.
While following the "common" build steps described here: How-to-build-for-Linux I have encountered a build error (when running the make command as the last operation of step 4).
The entire error output can be found here (now it is the last comment in the thread cpprestsdk-build-error#266).
Just to be sure my system has the needed build tools and libraries I performed the command mentioned in step 2 and this is the output:
--> Which means my system is "good to go".
So after I struggled it a little more, I have found "an alternative" way to build it:
I have downloaded the source code from here: Source Package: casablanca (2.8.0-2) [universe], and again, followed the same instructions STARTING FROM STEP 4 from the link mentioned in the question (How-to-build-for-Linux).
This time the make phase was successful !! (it is worth to mention that not all the unit tests that are recommended to be run on step 5 passed - I did not spend time trying to understand why...).
Went on and "copied-pasted" the complete sample provided at the bottom of the following link: cpprestsdk-Getting-Started-Tutorial.
Built the program with the following command (the program contained a single cpp file called main):
g++ -std=c++11 main.cpp -o myProg -lboost_system -lcrypto -lssl -lcpprest
Ran the program
./myProg
and it passed (there was output in the console saying:"Received response status code:200").
Would be glad to hear if you have encountered the same issue, or perhaps I did something wrong in my first attempt (or in any other step along the way).

Compiling DISLIN gfortran

I am having trouble compiling Fortran code with references to DISLIN. I have downloaded DISLIN from the website, unzipped the file and ran the setup. I have added an environment variable called DISLIN (C:\dislin) and added C:\dislin\win to the PATH section of my system variables.
I am trying to compile some example code of the DISLIN website which includes line
USE DISLIN
I am using a MinGW shell to compile with command gfortran -o progrname -ldislin EX11_1.f90 and am getting the following error:
Fatal Error: Cant open module file 'dislin.mod' for reading at (1): No such file or directory.
I have tried changing the variable path and even moving the dislin.mod file (which is there) but still get the same message.
Ok I fixed this problem so thought I come back and post what worked for me incase any one else needs it...
Install both DISLIN and MinGW on the c drive
Copy disgf.a from /c/dislin and dislin.f90 from /c/dislin/gf into the directory containing your fortran files
(for me this is /c/MinGW/pnote)
Using the MinGW shell navigate to you files: cd /c/MinGW/pnote
compile dislin.f90 and your fortran program: gfortran -c dislin.f90 progName.f90 (dislin.f90 obviously only needs to be done once)
link libraries etc and compile: gfortran progName.o disgf.a -luser32 -lgdi32 -lopengl32 -o exeName
'run' exeName
You probably need to specify the path to the DISLIN module files:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules
and, if not already configured like described here, also the path to the library itself:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules \
-L/path/to/DISLIN/library
They provide a batch file (windows) to do the compiling and linking for you.
f90link -c My_Program
This is located in c:\dislin\Win
Also, if you are having trouble with the dislin.mod file which resides in c:\dislin\gf then recompile that with the -c compile option. I found all of this info in c:\dislin\readme.inf
near as I can tell (Jan 2018) dislin (64 bit) fails miserably with gfortran 7.2, period; and probably with many other newer compilers.
When trying to link, gfortran 7 says 'dislin.mod' is an unrecognizable format.
I think this program is highly dependent on exactly correct version synchronization - something that renders such software useless imho after many years in research.
and no, the correctness of various 'paths' seems not to help.
after all, gnuplot works, "at all". Not sure why I spent so much time on brand x.
jrc

why am i seeing this libzdb configure error?

I am attempting to install libzdb on my macbook however I see the following error message when running the configure:
configure:13334: error: setjmp is required
the setjmp.h file resides within /usr/include and is specified within my "$PATH" as
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/include
Can someone please advise as to how i can rectify this issue?
thanks in advance
I've stumbled across this error while building one of my own programs when I wanted to use setjmp() and longjmp(). For some reason, the toolchain that resides in / on OS X is flawed, and the <setjmp.h> header file is missing the declarations and data types.
To fix it, I had to download Xcode (damn!) and tell the compiler to look for the headers in the freshly installed MacOSX10.7.sdk (or 8) folder:
clang -Wall -o foo foo.c -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
ok finally figured it out. For those who have seen messages like this be warned that the configure logs can be misleading. It turned out the binary built fine, however it was failing during runtime because a few mysql libraries could not be found. using the following command *export DYLD_LIBRARY_PATH=/usr/local/mysql/lib/* would fix the problem

calling sql from C++

my c++ program has sql code in it, and it runs fine on one linux machine but on the other, I get the following error when I compile it
g++ test.cpp -o a -L/usr/lib/mysql -lmysqlclient -lboost_date_time
fatal error: /usr/include/mysql/mysql.h: No such file or directory
compilation terminated.
I have mysql installed but I am obviously missing some step somewhere (on this machine with a new ubuntu installation)
can someone please let me know the fix. thx!
Looks like your computer doesn't have MySQL installed (in which case, install it), or is installed to a location other than /usr/include/mysql/mysql.h (in which case, change your compile command to point at the correct location)
You need to pass the location of mysql include files.
You are passing library location with:
-L/usr/lib/mysql -lmysqlclient.
If you know where mysql headers are you need to pass them to compiler using:
-I/path/to/directory/with/mysql/headers

Issues compiling vmware web api client code into useable objects

I'm using vmware's web application api in an attempt just to simply retrieve the fields in the "ServiceContent" object. There is an example of how this should be accomplished located at the vmware forum. The example contained there compiles fine for me however I get segfaults when running the simple example - specifically the trace goes back to the soap_serializeheader() function (I believe these are defined in stdsoap2.cpp). My problem is that I do not know how to avoid this segfault and have no idea why this is occurring (as I am following the example almost word for word). I am using OS X tool chain (gcc version 4.0.1 (Apple Inc. build 5465) ) combined with (gsoap release 2.7.16). I tried gsoap 2.8 but got the same result. Below is the procedure I used to get to where I am now.
These are the commands I used to parse the wsdl:
wsdl2h -o vim25.h vimService.wsdl
Once this is parsed, I compiled using the following command:
soapcpp2 -x -C -pvsp vim25.h -I/place/where/stlvector.h/is
this generates files vspC.cpp, vspClient.cpp, and vspVimBindingProxy.cpp. Internally these files have the same prefixes for functions (i.e. ns1/ns2 etc) so my calls are the same as those in the example.
This is the command I am using to compile vspC.cpp and vspClient.cpp:
g++ -DWITH_COOKIES -DWITH_OPENSSL -c vspC.cpp
g++ -DWITH_COOKIES -DWITH_OPENSSL -c vspClient.cpp
This is the command I use to compile stdsoap2.cpp (if I do not compile with -DWITH_NONAMESPACES I get an error about an undefined symbol "_namepspaces" when I link everything):
g++ -DWITH_COOKIES -DWITH_OPENSSL -DWITH_NONAMESPACES -c stdsoap2.cpp
I then link everything together with the test code (again this is copied almost identically from the example, just with the changes to correctly refer to the files I created):
g++ -DWITH_COOKIES -DWITH_OPENSSL vspC.o vcpClient.o stdsoap2.o testcase.cpp -lssl -lcrypto -o doesntwork
This compiles correctly, but of course fails to run. I read about an OS X user in this vmware forum post who was also having trouble. It appears the gsoap guide says you cannot use stdsoap2.cpp's header and fault serialization codes, and you must compile them separately. The user in the OS X post seems to have done this, however I am not sure how to incorporate them into my test file (he creates the empty env.h file and then compiles it with soap2cpp) - if I include the envH.h file i get about naming conflicts with vspH.h. So a second question would be how do I use soap2cpp to compile all the stubs correctly so that there are not namespace conflicts (which is what I appear to be encountering).
I will not provide the source, as it is displayed at the first vwmare forum link by user stumpr. I do not believe the issue is in the source, but in the way I have used either wsdl2h, soap2cpp, or some incorrect combination of flags during compilation with g++.
Thanks for taking a look, and hopefully some one can resolve the issue!
EDIT I think I may have solved this - by using a 64bit system (and one with more memory). I tried compiling with -m32 on the X.6 and it was not able to do it (complaining about memory issues).
Hopefully someone will stumble upon this and be happy to know the answer.