[mythtv-users] Wired article on TIVO macrovision patch
lachlan at directions.com.au
Fri Nov 12 02:07:00 UTC 2004
www.wired.com has an interesting article on the new tivo patch that enforces macrovision.
myth keeps looking better and better.
lachlan at directions.com.au
Mobile: 0409 641471
From: "Shawn"<core at enodev.com>
Sent: 12/11/2004 11:45:19 AM
To: "mythtv"<mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] Undefined symbol error when running CVS
I'm sorry if I wasn't clear, but what I was trying to portray was
Jarod's understanding of what was horked. I said "When libraries are
incompatible in such a way as you say, one of a number of things
happen", the key phrase being "as you say".
In fact, your assertion is more or less what I've been saying all along,
and thanks for mirroring it. You even use the phrase "binary
compatibility". I may have been wrong about why the problem existed in
the first place, but I was spot on on WHAT the problem was.
I believe Jarod to be wrong in that he said:
"I believe "That link error crap" as you so eloquently put it,
is CVS myth being built against 0.16 Myth libraries."
Myth links against the libraries it compiled
...and I get jumped all over for trying to help because I'm wrong? Teach
me to try and help anyone... Let it be known henceforth that all
would-be helpers will get the smack-down if they do not meet the
approval of Isaac Jarod, as judged by the cut of their jiff (sp?).
Let me put a point on it for anyone who chooses not to understand:
* I contend, as Isaac says below, that it's the binary trying to
run-time link with a library it was not compiled with, one which
is likely dangling outside the install prefix set in the CVS
* I did not state unequivocally that toolchain was to blame
* I may have been wrong about gcc/binutils being the cause of
binary compatibility (see above), but binary compatibility is
indeed what I originally described the problem to be.
On Thu, 2004-11-11 at 17:54 -0500, Isaac Richards wrote:
> > Here's the deal: If the myth program compile-time links successfully but
> > cannot run-time link successfully, it's binary incompatible, most likely
> > due to compiler or binutils. You may have written a document, but I'm
> > fairly certain you're wrong. When libraries are incompatible in such a
> > way as you say, one of a number of things happen:
> > 1. The program fails to compile-time link due to trying to pass the
> > wrong number or type of arguments to a given function
> > 2. The program fails to compile-time link due to trying to pass
> > seemingly compatibly structured data (type, number of args, etc)
> > but the data itself makes the function barf.
> > 3. The function returns incompatible type and compile-time link
> > fails
> > 4. The function returns seemingly compatibly structured data (type,
> > etc) but the data itself makes the calling code barf.
> > In other words, it probably won't compile, but if it does, it's image
> > will likely at least load into memory after /lib/ld-linux.so.2 is done,
> > and at some point it will probably segfault.
> Myth links against the libraries it compiled, in the source dir, at link time.
> When installed, the newly compiled libraries go into /usr/local/lib. The
> pre-existing shared libraries in /usr/lib from the old RPM install are seen
> first by the run-time linker, so they're used. Since they're old, and since
> the constructor's signature has changed since 0.16 (and so making the
> existing binary compatability test in the source code not work properly),
> they're not compatible with the new mythfrontend binary. Because of this,
> you get an error similar to that of the original poster.
> The problem has absolutely nothing to do with what you assert that it does.
More information about the mythtv-users