OpenBSD Port

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 14, 2009 at 6:15 PM, Christopher Zimmermann
<madroach at zakweb.de> wrote:
> Hi,
>
> yesterday I ported the pjproject to OpenBSD. Diffs are attached.
> pjsua works fine.

Hi Christopher,

thanks for the efforts! Frankly I never tried to run pjsip on any BSDs myself.

> As you can see the 4th patch is OpenBSD specific and will break other
> OSes. But I could not find a clean solution to this, because I do not
> really understand your build system.
> What I needed to do was to disable the portaudio in third_party and
> instead link in the one supplied with OpenBSD, since it is patched to
> support OpenBSDs libsnd. Maybe someone else knows how to fix it
> properly.
>

What I wanted to do in this area is to support using third party
libraries outside third_party directory. It's also common in Linux to
have distros that ship PA, speex, etc., and having the ability to use
these libraries would make pjsip "more friendly" packaging wise.

So my approach on this would be to add something like
"--with-external-portaudio[=PATH]" configure option, which would be
propagated throughout the Makefiles.

> For the first three patches it would be nice to see them committed to
> svn.
>
>
> When running pjlib-test two tests fail:
>
>
> udp_ioqueue_unreg_test (gdb session attached)
>
> failes in os_core_unix.c pj_mutex_destroy().
> I added an assertion to the return code of pthread_mutex_unlock(). And
> it turns out that it is EPERM meaning the current thread doesn't hold a
> lock on the mutex. To me this looks like a bug in pjproject, not
> OpenBSD.
>

This is not fatal, but an error nevertheless. On some *nix systems
(probably OpenBSD included), pthread_mutex_destroy() fails if the
mutex is in locked condition, so pj_mutex_destroy() tries to unlock it
before destroying the pthread mutex. If these operations fail, we'll
have a mutex handle leak.

I don't think we have (many) situations like these in real
applications, so the error might be in pjlib-test. But this is just a
guess.

>
> activesock_test (backtrace and output attached)
>
> locks up in poll()
>

There could be some differences in the way TCP works with select() in
OpenBSD. Will need to check that out.

>
> When running pjsip-test only tsx_bench fails (gdb session attached)
>
>

That means that we have problem with the unique ID (GUID) generator
which doesn't seem to be good enough in supplying us with unique IDs.

I'll see what I can do in 1.6 for this. In the meantime, I just
created http://trac.pjsip.org/repos/ticket/994 as my reminder.

Thanks!
 Benny

>
>
> cheers,
>
> Christopher Zimmermann



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux