Any developer around that can take a look at this? Thanks, On Sun, Jun 3, 2012 at 4:12 PM, Federico Schwindt < federico.schwindt at gmail.com> wrote: > Hi, > > While I was trying to get the python bindings working on OpenBSD/amd64 and > testing several other things I found a number of issues. Although this is > based on 1.14.2, a brief inspection shows that this is still valid for 2.0. > The attached diffs try to deal with them: > > unlock_before_destroy.diff: > > In POSIX 2008 destroying a mutex before is unlocked is undefined. The spec > recommends returning EBUSY but it's not mandatory and might differ > depending on the implementation. > More of this below. > > override_CFLAGS.diff: > > If you tried compiling the python bindings on amd64 you'll have a tough > time since the objects are compiled for static libraries (sorry, no offense > but I could not avoid somewhat ranting about it). I've created a user.mak > that basically adds -fPIC to the needed CFLAGS but a few libraries under > third_party didn't allow for this. This diff fixes it. > FWIW, I've also attached the user.mak that perhaps could be added to the > documentation as an interim solution. > > As for destroying the mutex before unlocking it there is one place that > stills needs to be fixed. This is tsx_destroy() > in pjsip/src/pjsip/sip_transaction.c. > There are 2 ways that this function is called. Sometimes unlock_tsx() is > called before so the mutex is already unlocked and sometimes is called > afterwards (i.e. tsx_timer_callback()). > Obviously the second is a problem. There is also the somewhat ugly hack > (IMHO) to avoid unlocking the mutex after it's been destroyed which is a > side effect of the way tsx_destroy() and unlock_tsx() interact. > > There are several approaches to fix this but without some major surgery > the code ended a bit on the fugly side. I might take a look later but I > wanted to get this out. > > I'm not subscribed to the list so I'll appreciate if you CC me. > > Thanks, > > f.- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120608/3586edea/attachment.html>
