KDE 4.5 libraries problem with Skype
1i5t5.duncan at cox.net
Tue Aug 31 03:35:54 BST 2010
Manuel Escudero posted on Mon, 30 Aug 2010 18:48:54 -0500 as excerpted:
> I have installed Fedora 13 Goddard x86_64 in my machine and I've updated
> to KDE 4.5, in order to run Skype I installed some 32 bit Qt libraries
> and when I installed the new KDE desktop I had to remove them because
> KDE 4.4 uses the "1:4.6" version of these libraries and KDE 4.5 the
> "1:4.7"... Now I have KDE 4.5 and everything is fine but I can't run
> lastest Skype because it needs the "1:4.6" Qt libraries, it doesn't work
> with the new ones, but if I remove the new ones and I replace them with
> the older ones, many apps seem to be "downgraded" or they just don't
> work anymore... Does this mean we're not having Skype in any KDE Linux
> distro of 64 bit with the new KDE 4.5 installed?
> Many users need skype (in my case I'm running it in a Windows 7 VM) But
> without it we can't offer a reliable service to the Linux User who uses
Of course, skype's proprietary servant-ware. They have no respect for
your freedom and you're at their mercy, as here. At least when kde
dropped kde3, it was possible for someone to pick up the pieces and
continue with it, and that's exactly what has happened (tho their success
over a longer term remains to be seen). With proprietaryware, you're
simply left "up a creek without a paddle", as they say, totally at the
mercy of the provider who has already demonstrated a lack of respect for
the rights of their users, in terms of what the provider chooses to do
support-wise and upgrade-wise. This is just one more example (tho I
expect they will eventually upgrade).
Now I'm not going to pretend to be able to make the choice for someone
else, as unlike some softwaire providers, I actually do respect the
freedom of others (tho as it is said, their freedom ends where my nose
begins... tho unfortunately, many don't see it that way). However, it's a
definite risk that people take, and they really should be aware of the
implications of their choice when they make it. Once they are, great, but
too often people don't realize those implications, which is just... sad.
If this post causes one person to think a bit before they make the choice,
regardless of which choice they then make, it has done its job.
All that said, for those who /do/ go prorietary for some of their
At least for amd64 (aka x86_64), the problem shouldn't be too bad, because
32-bit and 64-bit libraries can be kept in different locations and
shouldn't interfere with each other. If you're running 64-bit kde, then
you're using 64-bit qt4 libraries. They should be upgradeable without
worrying about any 32-bit versions of the libraries you may have to keep
around for compatibility with black-box software that hasn't upgraded yet,
and that you have no practical way of fixing the upgrade issues with
Now, whether the package manager is sufficiently advanced to properly
track both the 32-bit and 64-bit versions separately, is an entirely
different question. I'm on Gentoo, and know our package managers have
problems in that regard (tho I also know there's a documented solution,
which I use to solve a different problem, as I have a separate 32-bit
build-image chroot install on my main 64-bit machine, which I use to build
the Gentoo image for my 32-bit-only netbook), but I had actually thought
that Fedora was a leader in multi-lib compatibility, and am surprised
you're having the issue, there.
But as I mentioned, there is definitely a solution possible. If your
package manager can't handle it directly, one possible workaround is a 32-
bit chroot install on the same machine.
Actually, the same solution should work for 32-bit/32-bit as well. Just
because the main native install is 64-bit doesn't make it different in
that regard. A 32-bit system should be able to handle a separate chrooted
install, with one upgraded and the other kept at early versions for
Of course, that's a bit extreme. A reasonable multilib solution will work
in most cases. I'm just pointing out that if it's not provided by your
distributor, there are ways of taking the solution into your own hands,
even if they are a lot more work at the individual system level (as
opposed to the distribution level) than a multilib solution would be, for
the same problem.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde