[mythtv] Linking problem

Sam Varshavchik mrsam at courier-mta.com
Sun Feb 18 03:17:50 UTC 2007

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…


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.  

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 

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070217/eeec019f/attachment.pgp 

More information about the mythtv-dev mailing list