[mythtv] Linking problem

Trampas tstern at nc.rr.com
Sun Feb 18 17:41:33 UTC 2007


Thanks again for your help!

Trampas

-----Original Message-----
From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Sam Varshavchik
Sent: Sunday, February 18, 2007 11:19 AM
To: Development of mythtv
Subject: Re: [mythtv] Linking problem

Trampas writes:

> Sam,
> 
> Hahaha, well of course the first thing I did was try to build Myth with
out
> reinstalling QT. Of course it would not work as that MythTV need qmake.

And, if you bothered to do you homework first, instead of forging ahead 
blindly, you would've discovered the qt-devel package ("devel" as in 
"development"), which contained the qmake command, oh, for the last six 
years or so -- pretty much since QT came on the scene.


> 
> Trampas 
> 
> 
> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
> On Behalf Of Sam Varshavchik
> Sent: Saturday, February 17, 2007 10:18 PM
> To: Development of mythtv
> Subject: Re: [mythtv] Linking problem
> 
> Trampas writes:
> 
>> I do have the 'yum' version installed, but there were a couple of bug
> fixes
>> I needed for my HdHomeRun device. Also there are a couple of things I
> would
>> like to fix in the code.
>> 
>> Here are the steps I followed:
>> 
>> #1 install QT 3.3.7, following directions in the INSTALL/README file
> 
> If your only issue is with hardware support, you don't need to rebuild qt.

> qt is just a GUI toolkit.  You just gave yourself a lot of extra work, all

> for nothing.
> 
>> #2 check out mythtv
>> #3 Do a ./configure in the mythtv directory
>> #4 issue make in the mythtv directory. 
> 
> This is going to be a bitter pill to swallow, but you really need to 
> understand something.
> 
> Never, ever, manually build or install anything like this, on any Linux 
> distribution that uses rpm/yum.  Over time, you're going to destabilize
your
> 
> system.  At some point in the future other applications or utilities will,

> one day, begin mysteriously failing with strange error messages, all of a 
> sudden.  Things will break randomly, and giving you a lot of grief.  Your 
> abnormal linking error is just a taste of things to come.
> 
> Without fail, it's a certainty that a bunch of cowboys are going to make 
> their appearance, right about now, pouting that they've been manually 
> compiling and installing all sorts of software for many years, like that, 
> and they never had any problems.
> 
> Well, you'll just have to choose who to believe, them or me.  I'll just 
> explain to you that yum and rpm do more than just install a bunch of files

> that make up a software package. They keep track of shared library 
> interdependencies between all the packages installed on the system,
prevent 
> you from removing packages that contain files that are still needed by
other
> 
> packages that you have installed, prevent you from installing incompatible

> packages, with conflicting files, and do a lot of stuff behind the scenes 
> that, hopefully, keep everything that you have installed running smoothly,

> and function as a safety lifeline to keep you from fscking up your system 
> with a bad install.
> 
> But here you go -- with your configure/make/make install -- dumping a
bunch 
> of files all over the place.  Of course, rpm/yum knows nothing about what 
> you're doing.  Unless you installed an rpm package, using the rpm or the
yum
> 
> command, it doesn't exist, as far as they are concerned.  And you do 
> understand that if 'make install' tries to install a file that's already 
> there, it'll just unceremenously overwrite it, without a second thought?  
> Even if the file is a key, core shared library component?
> 
> You probably ended up overwriting the files in your Linux distribution's
qt 
> package with the files from your own custom-made package that was built 
> differently than the distribution's package.  As such, the binary ABI is 
> likely to be different than the binary ABI of _all_ qt applications that
you
> 
> have installed, but as far as rpm/yum is concerned, the original qt
package 
> is still installed, and there's no conflict whatsoever.  Everything is 
> peachy-keen.  The sun is shining.  The bird are singing.  Pay no attention

> to an unseemly, smelly ditch that runs through the middle of the lawn.
> 
> Chances are that most of the things will continue to work for you maybe
99% 
> of the time.  Until that remaining 1% bites you in the arse, and you'll be

> asking WTF just happened, and nobody could help you, because nobody that 
> uses standard, pristine, non-corrupted package libraries has ever seen 
> anything like what happened to you.
> 
>> I read that the QT needs to be built with mySQL and threaded support.
> 
> Yes, and the pre-built QT package that you already had, before you
ventured 
> off into unknown territory, was already built with all of these options.
> 
> <sigh>
> 
> All you had to do was install the qt-MySQL package, with yum, and you 
> would've been ready to go.  And the funny thing (but I don't think you're 
> laughing) you probably already did.  If you had MythTV previously
installed,
> 
> via yum, its package interdependency resolution logic would've
automatically
> 
> installed it for you.  When you went to install the prebuilt mythtv
package,
> 
> yum would've noticed that it lists "qt-MySQL" as a needed dependency.  The

> individual who built the mythtv rpm package knows what he's doing.  He
knows
> 
> that mythtv needs mysql support in qt, and explicitly put the dependency 
> into the rpm package.  Then, when you went to install it, yum checked if
you
> 
> had qt-MySQL installed, and if it didn't, it installed it for you.
> 
> And on all modern Linux distros, qt is already built with threading
support,
> 
> and has been built this way for a long time.
> 
> It's one thing to take some third party software application and try to 
> install it yourself, without using rpm tools.  It's quite a different
story 
> when you take a core, critical system component library like qt, and blow 
> away your the existing package, that was tested to verify that it worked 
> correctly with everything else on your system that uses qt.  You just
nuked 
> it from high orbit, and replaced it with a manually-built qt package.  
> Congratulations.
> 
> Unless you really, _really_, know what you're doing, or unless you get 
> extremely likely, you now have a big mess on your hands.
> 
>> According to the QT setup it is built with threaded but I did not see an
>> option for MySQL.
> 
> <sigh> Qt's MySQL support is in a separate qt-MySQL package.
> 
> Any advice anyone will give you will be nothing more than a random guess.

> Your system has been destabilized, after some key, core system shared 
> libraries and development toolkits were replaced by manually-built stuff 
> that was likely not configured identically to how the original system 
> packages were configured and set up.
> 
> I understand that the myth rpm packages didn't work for you due to some 
> hardware configuration issue.  The way that this kind of an issue should
be 
> fixed is:
> 
> 1) Grab the source rpm for the package that needs to be fixed -- in this 
> case it's mythtv, _not_ Qt.  Qt has nothing to do with hardware support.
> 
> 2) Take the source rpm apart.  Either replace the upstream tarball in the 
> source rpm with a newer version, or integrate the required patch into the 
> rpm spec file, and rebuild.  Patch/fix/do whatever needs to be done with
the
> 
> rpm spec file, to get the new package built.  Bump the release number if 
> necessary.
> 
> 3) Take the new binary rpm packages, and install them.
> 
> Yes, that means that one needs to learn how to create rpm packages.  Yes, 
> it's a pain in the arse.  But the alternatives are much worse than a pain
in
> 
> the arse.  One typo in the configure script, or make install, and you have
a
> 
> doorstop on your hands.  System doesn't even boot.  Time to reinstall
Linux 
> from scratch.




More information about the mythtv-dev mailing list