[mythtv] Ticket #3062: Freebsd compatibility patches
usleepless at gmail.com
usleepless at gmail.com
Thu Feb 8 14:52:54 UTC 2007
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
More information about the mythtv-dev
mailing list