Bug 802914

Summary: gsoap rpms don't allow for multi-server/client/custom C++ namespace builds
Product: [Fedora] Fedora EPEL Reporter: David Rennalls <david_rennalls>
Component: gsoapAssignee: Mattias Ellert <mattias.ellert>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: mattias.ellert
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-14 17:33:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Rennalls 2012-03-13 18:32:24 UTC 
Description of problem:
I have some existing code that directly compiles and links in stdsoap2.cpp and uses -n and -p for the code generation with a custom C++ namesapce. for e.g.
soapcpp2 -n -pmyPrefix

..this allows multi-client/multi-server builds and removes the dependency on a global namespaces table, see http://www.cs.fsu.edu/~engelen/soapdoc2.html#sec:compilerflags
http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc19.35

However doing so requires that stdsoap2.cpp be directly compiled in with -DWITH_NONAMESPACES or an external gsoap lib be built with -DWITH_NONAMESPACES and linked against.

So when I switch from my current build setup to using the EPEL gsoap rpm I get the following linker error..
g++ -o test test.cpp ...etc..  -lmysoapclient
/usr/lib/libgsoap++.so.0: undefined reference to `namespaces'
collect2: ld returned 1 exit status
make: *** [test] Error 1

...since all the .so's in the gsoap rpm are not built with -DWITH_NONAMESPACES they're expecting client/server code with a global namespaces variable to be linked against.
[~]$ ldd -r /usr/lib/libgsoap*.so 2>&1 | grep "undefined.*namespaces"
undefined symbol: namespaces    (/usr/lib/libgsoapck.so)
undefined symbol: namespaces    (/usr/lib/libgsoapck++.so)
undefined symbol: namespaces    (/usr/lib/libgsoap.so)
undefined symbol: namespaces    (/usr/lib/libgsoap++.so)
undefined symbol: namespaces    (/usr/lib/libgsoapssl.so)
undefined symbol: namespaces    (/usr/lib/libgsoapssl++.so)

Version-Release number of selected component (if applicable):
]$ rpm -q gsoap
gsoap-2.7.16-3.el6.i686

How reproducible:
Always

Steps to Reproduce:
1. Use 'soapcpp2 -n -p<a prefix>' for the code generation and then link against one of the gsoap shared libraries.
2.
3.
  
Actual results:
/usr/lib/libgsoap++.so.0: undefined reference to `namespaces'

Expected results:
for things to link ok :)

Additional info:

Can the libs be built with -DWITH_NONAMESPACES or the stdsoap2.cpp file be included in the gsoap-devel rpm ?
Comment 1 Mattias Ellert 2012-03-14 17:33:00 UTC 
Hi!

We are using soapcpp2 with the -n and -p flags in our own projects with the libraries provided by the gsoap package without problems. What we do is to provide an empty global namespace to satisfy the undefined symbol:

cat namespaces.cc
#include <stdsoap2.h>
extern "C" {
SOAP_NMAC struct Namespace namespaces[] = { { NULL, NULL} };
}

Or for a C project:

cat namespaces.c
#include <stdsoap2.h>
SOAP_NMAC struct Namespace namespaces[] = { { NULL, NULL} };
Comment 2 David Rennalls 2012-03-15 14:07:06 UTC 
yes I know I *could* do that to satisfy the dependency but that's really a kludge..