[reSIProcate] Solaris status (libCstd or stlport?)

[Adam Roach]

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