[csw-maintainers] libCstd or stlport?

[Daniel Pocock]

On 21/04/12 21:54, Dagobert Michelsen wrote:
> Hi Daniel,
> 
> Am 20.04.2012 um 21:42 schrieb Daniel Pocock:
>> 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?  Is there a
>> convenient way to get versions of the dependencies that are not libCstd
>> dependent?  Or does the upstream project need to drop the requirement
>> for stlport?
> 
> Unfortunately you are right:
>   http://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
> "STLport is binary incompatible with the default libCstd"...
> 
> I guess we need a special version like the gxx tree for libCstd and stlport.
> However, it is worse with stlport as the shipped 4.5.3 *may* be incompatible with
> any other version of stlport in the future as also said in the linked document.
> I suggest having /opt/csw/stlport and see how far we can get. Regarding BDB I guess
> that I will rebuild 4.8 against stlport as modulation or different branch and
> see if that solves the issue. Unfortunately I probably won't be able to do that
> before start of next week.
> 

I had a closer look at the resip code

I fixed all the issues discussed in the other email thread (e.g. the
const stuff)

I then tried the libCstd compile, and got the new problems.  Some of the
issues were just similar to the prototype problems that were discovered
last week.  The compiler seems to be more strict when using libCstd than
using stlport

However, I now get stuck on a much more messy looking error regarding
templates.  I'm going to post that on the resiprocate list and see if
anyone familiar with the code has suggestions.  It may or may not be
possible to adapt resiprocate for libCstd