Re: [reSIProcate] Solaris status (libCstd or stlport?)
On 4/20/12 3:50 PM, Daniel Pocock wrote:
I notice that reSIProcate has previously been compiled on Solaris using
-library=stlport, and I believe this is still necessary or the code
doesn't compile. Without -library=stlport, it stops like this:
libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I..
-I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc
-DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT
-DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o
"DnsUtil.cxx", line 550: Error: Formal argument x of type const
std::pair<resip::Data, resip::Data>& in call to
std::list<std::pair<resip::Data, resip::Data> >::push_back(const
std::pair<resip::Data, resip::Data>&) is being passed std::pair<char*,
resip::Data>.
1 Error(s) detected.
However, I noticed that dependenices (e.g.
/opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd
If I add -library=stlport, the code builds, but the repro binary fails
with a Segmentation fault, before it even enters the main function. The
stack trace shows a combination of libCstd and stlport classes.
Can anyone comment on how to deal with this situation? Should libCstd
be supported?
Okay, after studying the error message, this looks like a bug in libCstd
under Solaris. For some reason, it's failing to perform an implicit
conversion from "std::pair<char*,resip::Data>" to "const
std::pair<resip::Data,resip::Data>&".
There are three places this could be going wrong. The two that seem
least likely is the implicit conversion from non-const to const, and the
conversion to a reference (if it had an issue with the pair being
temporary, I would expect the error to mention as much -- beyond which
I'm pretty certain push_back's contract is one of copying, in which case
a temporary causes no issue). The third thing that might go wrong -- and
the one I suspect -- is conversion from char* to resip::Data (which has
a perfectly good implicit constructor of the form "Data(const char* str);").
I don't have a working Solaris VM at the moment, but I would suggest
changing the line to read:
results.push_back(std::pair<Data,Data>(*_name, ip));
...and see if that eliminates the error with libCstd.
Also: how pervasive is this issue? If you do a "make -i," how many such
errors arise over the course of compilation?
/a