[reSIProcate] Solaris status (libCstd or stlport?)

[Adam Roach]

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

> "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?

> "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);
    }


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).

> "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)

Let me know if any of my suggestions get you closer to working with 
libCstd. Meanwhile, I'll continue, when I have time, to try to get a 
Solaris VM in a state that lets me try compiling.

/a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120424/ad9bb744/attachment.htm>