[csw-maintainers] libCstd or stlport?

[Daniel Pocock]

On 24/04/12 15:08, Dagobert Michelsen wrote:
> Hi Daniel,
> 
> Am 21.04.2012 um 21:54 schrieb Dagobert Michelsen:
>> 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 have now updated libstlport.so.1 to the latest patchlevel and build bdb 4.8
> against stlport available at
>   http://buildfarm.opencsw.org/experimental.html#stlport
> 
> If you want I can install these for you on the testing hosts. Is there a specific
> ISA you want to test?

I've had a play with things in the resip stack itself - I've now got it
working with libCstd.  In the long run, I think the stlport stuff will
make OpenCSW more flexible, but it is not blocking resiprocate any more.

I found some limitations of libCstd:

- remove_if doesn't want to take an object as a predicate, it only wants
a non-object function pointer

- auto-boxing doesn't work in some cases, it is necessary to be more
explicit

- odd errors about casts appear when trying to use a custom allocator
with std::list.  I've reverted to the default allocator (the custom one
is there for performance reasons)

- the compiler also seems even more pedantic about function prototypes
in headers if I use libCstd rather than stlport

If you want to see the details of things that needed tweaking and how I
solved each of them, it is all logged here:

http://list.resiprocate.org/archive/resiprocate-commit/