[mythtv] Ticket #3062: Freebsd compatibility patches

[usleepless at gmail.com]

Daniel, List,

On 2/8/07, Daniel Kristjansson <danielk at cuymedia.net> wrote:
> On Thu, 2007-02-08 at 13:53 +0100, usleepless at gmail.com wrote:
> > On 2/8/07, MythTV <mythtv at cvs.mythtv.org> wrote:
> > > #3062: Freebsd compatibility patches
> > > Comment (by nigel):
> > >  mainserver.cpp - What is the problem with the lock?
> >
> > well, that's a good question. i don't know either. but
> > mythbackend<->mythfrontend communication only works when these locks
> > are disabled. otherwise commands timeout and nothing happens ( this is
> > the patch that took me a real long time to find ). this is the problem
> > most freebsd people encountered but couldn't solve.
>
> It would be best if you could debug the locking problem,
> disabling the locks will probably just result in a different
> problem. Just run under gdb and hit Ctrl-C when it locks
> up, then a backtrace should show you were the lock contention
> is located.

i will try that when i have time for it ( for the time being i think
this is a very well working patch for freebsd, and i already invested
considerable time finding this patch ). you might want to give it a go
on linux as well.

i should note that the guy who owns the box where i developed this
patch, tested mythtv several times and it was working just fine. also,
i have been running with the readReadyLock disabled on my own
0.18-fixes for months now as well ( socket is still locked, i will
remove that too ).

i for one do not understand why the readReadyLock is there. the stuff
that's needs locking ( the threadPool ) is locked, and i would think
that should suffice. with the readReadyLock in place only one thread
at a time is able to call MainServer::readSocket.

i don't known/understand why the socket is locked either ( and will
try to remove it on my 0.18-fixes ).

> > >  [[BR]]
> > >  videoout_xv.cpp - I suspect NetBSD also lacks malloc.h. It should
> probably
> > >  be:
> > >  {{{
> > >  #ifdef _linux_
> > >  #include <malloc.h>
> > >  #endif
> > >  }}}
> > malloc.h is deprecated on FreeBSD. do i need to resubmit the patch
> > with this changed?
>
> I don't need "malloc.h" on my Linux system. Does anyone know
> what OS "malloc.h" is needed for?
>
> > >  yuv2rgb.cpp - Don't see the need. The values should all be small
> positives
> > >  (''e.g.'' UCHAR_MAX is 255)
> > fails to compile otherwise.
>
> What is the error message?

that is strange: on my own box ( 6.1, gcc3.4.4 ) is doesn't error.

but if i go to the amd64-mythtv-0.20-box ( 6.2, gcc3.4.6 ) is does error:

In function `void yuv420_argb32_non_mmx(unsigned char*, unsigned ch
ar*, unsigned char*, unsigned char*, int, int, int, int, int, int)':
yuv2rgb.cpp:444: error: no matching function for call to `min(unsigned int, cons
t int&)'

me thinks that it might have to do with different mmx-detection ( ie:
mmx is detected on my own machine and hence no compile error ).

optimization is O3 btw.

> > >  [[BR]]
> > >  version.pro - Curious. What is the behavior without the sh -c ?
> > >  [[BR]]
> > command fails. doesn't produce version.cpp, build fails.
>
> Nigel, "sh -c" should be ok on Linux, what about Darwin?

thanks for following up so prompt,

regards,

usleep