Re: [reSIProcate] Solaris status (libCstd or stlport?)

[Adam Roach <adam@xxxxxxxxxxx>]

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