Bug 802914 - gsoap rpms don't allow for multi-server/client/custom C++ namespace builds
gsoap rpms don't allow for multi-server/client/custom C++ namespace builds
Status: CLOSED WORKSFORME
Product: Fedora EPEL
Classification: Fedora
Component: gsoap (Show other bugs)
el6
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mattias Ellert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 14:32 EDT by David Rennalls
Modified: 2012-03-15 10:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-14 13:33:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Rennalls 2012-03-13 14:32:24 EDT
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 13:33:00 EDT
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 10:07:06 EDT
yes I know I *could* do that to satisfy the dependency but that's really a kludge..

Note You need to log in before you can comment on or make changes to this bug.