Re: [reSIProcate] Solaris status (libCstd or stlport?)
On 25/04/12 23:15, Daniel Pocock wrote:
>
>
> On 25/04/12 04:50, Adam Roach wrote:
>> I'm downloading a Virtualbox VM of Solaris 10 to see if I can fix some
>> of these things myself, but it's going to take a couple of hours (!) to
>> download, and I'm still pretty strapped for time.
>>
>> In any case, there appear to be two classes of problem here, and I think
>> you've already figured out the solution to one of them. Comments inline.
>>
>>
>> On 4/23/12 16:49, Apr 23, Daniel Pocock wrote:
>>>
>>> I've done two runs of `make -i', once to build everything that does
>>> build, and a second time just to get the error output as it tries to
>>> build everything that failed. Here is a summary:
>>>
>>>
>>> SipMessage.cxx (errors from above):
>>> "/opt/studio/sunstudio12.1/prod/include/CC/Cstd/./memory", line 483:
>>> Error: Using static_cast to convert from std::pair<resip::Data,
>>> resip::HeaderFieldValueList*>* to std::list<std::pair<resip::Data,
>>> resip::HeaderFieldValueList*>,
>>> resip::StlPoolAllocator<std::pair<resip::Data,
>>> resip::HeaderFieldValueList*>, resip::PoolBase>>::__list_node_buffer*
>>> not allowed.
>>
>> This doesn't point to a specific line in SipMessage.cxx, but the
>> signature does match the one instance of make_pair() in the file, on
>> line 1139:
>>
>> mUnknownHeaders.push_back(make_pair(headerName.getName(), hfvs));
>>
>> This is exactly the same pattern as what was holding up DnsUtil.cxx.
>> Perhaps the same fix as you implemented for that problem can be applied?
>>
>> http://svn.resiprocate.org/viewsvn/resiprocate/main/rutil/DnsUtil.cxx?r1=9584&r2=9585&diff_format=l
>>
>
> I tried commenting out line 1139, it doesn't make the error go away
>
> In the header file (memory:483), the static_cast is within the
> definition of the allocator_interface template:
>
>
> template <class _Allocator,class _Tt>
> class allocator_interface
> ....
> pointer allocate(size_type n, pointer p = 0)
> {
> return _RWSTD_STATIC_CAST(pointer,alloc_.allocate(n*sizeof(_Tt),p));
> }
>
>
> I haven't looked any more closely at this, I will have another look
> tomorrow if you can't see any quick solution
Ok, I've simply removed the custom allocator stuff (for Solaris users
only) and that makes it compile
It appears to be an issue with the way that SipMessage::UnknownHeaders
was defined with custom allocator (rutil/StlPoolAllocator):
http://list.resiprocate.org/archive/resiprocate-commit/msg06776.html
I'm now running the test cases with:
gmake -C resip/stack check
on Solaris, looking good so far.
>
>>> "TransportSelector.cxx", line 215: Error: Could not find a match for
>>> std::multimap<resip::Tuple, resip::Transport*,
>>> resip::Tuple::AnyPortAnyInterfaceCompare, std::allocator<std::pair<const
>>> resip::Tuple, resip::Transport*>>>::insert(std::pair<resip::Tuple,
>>> resip::Transport*>) needed in
>>> resip::TransportSelector::addTransportInternal(std::auto_ptr<resip::Transport>).
>>> 1 Error(s) detected.
>>
>> The line in question is:
>>
>> mTypeToTransportMap.insert(std::make_pair(tuple,transport));
>>
>>
>> Which is the same pattern again: inserting a pair created with
>> std::make_pair into an STL collection. I suspect the same fix should work?
>
>
>
> Not quite... but I found this variation works for libCstd:
>
> - mTypeToTransportMap.insert(std::make_pair(tuple,transport));
> +
> mTypeToTransportMap.insert(TypeToTransportMap::value_type(tuple,transport));
>
>
> so that is committed
>
>>
>>> "InMemoryRegistrationDatabase.cxx", line 243: Error: Cannot cast from
>>> RemoveIfExpired to bool(*)(const resip::ContactInstanceRecord&).
>>
>> This is a different beast.
>>
>> The offending line is:
>> contacts->remove_if(RemoveIfExpired());
>>
>> ...where "contacts" is of type "ContactList".
>>
>> For clarity, ContactList is defined thus:
>> typedef std::list<ContactInstanceRecord> ContactList;
>>
>> And the contract on std::list for "remove_if" is described like this:
>>
>> template <class Predicate>
>> void remove_if ( Predicate pred );
>>
>>
>> Predicate /pred/ can be implemented as any typed expression taking one
>> argument of the same type as the list and returning a bool (this may
>> either be a function pointer or an object whose class implements
>> operator()).
>>
>> It's possible that the compiler would be happier if we were explicitly
>> creating an instance of the class on the stack rather than just creating
>> it as part of the "remove_if" statement. See if this works better:
>>
>> if(mCheckExpiry)
>> {
>> RemoveIfExpired rei;
>> ContactList *contacts = i->second;
>> contacts->remove_if(rei);
>> }
>
> Tried this, it still isn't happy
>
>>
>> If that doesn't work, it's possible that the Solaris implementation just
>> doesn't get the predicate contract right, and we may need to wrap the
>> class up in a function pointer (as I'd like to believe the
>> implementation isn't /completely/ broken).
>
> Just doesn't work with libCstd unless I use a normal function pointer
> (not a class) - so that committed now, for SunPro only
>
>
>>> "InMemorySyncRegDb.cxx", line 58: Error: Cannot cast from
>>> RemoveIfRequired to bool(*)(const resip::ContactInstanceRecord&).
>>> "InMemorySyncRegDb.cxx", line 311: Error: Cannot cast from
>>> RemoveIfRequired to bool(*)(const resip::ContactInstanceRecord&).
>>> "InMemorySyncRegDb.cxx", line 341: Error: Cannot cast from
>>> RemoveIfRequired to bool(*)(const resip::ContactInstanceRecord&).
>>>
>>
>> This is the same problem as above. If the above solution works, it
>> should apply here as well.
>>
>> RemoveIfRequired rir(now, mRemoveLingerSecs);
>> contacts.remove_if(rir);
>>
>> (In all three places)
>
> Not quite... the function pointer solution can't be used with the
> argument mRemoveLingerSecs
>
> The only quick solution I can see here is to iterate explicitly, so I've
> implemented that (using #ifdef for SunPro only)
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel