[mythtv] Linking problem
tstern at nc.rr.com
Sun Feb 18 15:38:08 UTC 2007
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.
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
> I do have the 'yum' version installed, but there were a couple of bug
> I needed for my HdHomeRun device. Also there are a couple of things I
> 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
> #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
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
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
More information about the mythtv-dev