Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: AMD64 linking issues.
Date: Fri, 15 Jul 2005 12:21:12
In Reply to: [gentoo-amd64] AMD64 linking issues. by Tres Melton
Tres Melton posted <1121406115.808.429.camel@×××××××××.org>, excerpted
below,  on Thu, 14 Jul 2005 23:41:55 -0600:

> "equery belongs" returned both > kde-base/kdelibs-3.3.2-r9 and kde-base/kdelibs-3.4.1-r1. Do I even need > 3.3.2 if I have 3.4.1? Just to be safe with some of the older packages I > didn't --unmerge it. Manually trying to re-emerge kde-base/kdelibs > ("emerge -avDt --newuse kde-base/kdelibs") yielded a number of "Error: > libgd was not built with FreeType font support" which could be an insight > into the problem as media-libs/libgd is a part of the mplayer32 package > and not available as a 64 bit package. In my opinion kdelibs should not be > linking against a 32 bit binary library. Anyway, that is where it stands > at the moment, re-emerging kdelibs didn't change anything.
Do you need both kdelibs 3.3.2-rX and 3.4.1-rX?? Depends on what you /want/ installed. AFAIK KDE is slotted, so KDE 3.3 and 3.4 can be installed in parallel. Note that they install into /usr/kde/3.3 and /usr/kde/3.4, and you can keep separate user settings for them as well, by keeping separate ~/.kde3.3 and 3.4 dirs. I've always ensured I have only the latest installed, to prevent any strange complications (maybe related to the complication at hand??), altho I'd possibly keep KDE 3.5.x (which will be the latest 3.x release by then) around, with qt3 of course, when I first start testing KDE4 betas (on Qt4.x, naturally) sometime next year. (I remember the 2.x to 3.x upgrades... Note that KDE-non-core apps may well not be upgraded in sync and remain at KDE/Qt 3.x versions for awhile...) Depending on what else you have installed and your other settings, it may in fact be your old KDE version that's being run. Anyway, if you've no specific reason to keep the old slotted versions around, might as well unmerge them. Keep in mind that you /may/ have to remerge KDE-non-core apps, or run or the like, after removing the old versions, for things like k3b, klibido, krename, kmplayer and kbear (the non-core KDE apps I run here). You may also wish to run emerge --pretend --prune, do **NOT** forget that --pretend in this case, and take a LOOK at the LIST it spits out. That will be all the packages INCLUDING SLOTTED PACKAGES where more than one version is merged. **DO** **NOT** **JUST** **UNMERGE** **THEM** **ALL**!!! Many of them will be packages (like autoconf, automake, perhaps gcc, even gtk+-1.x vs. 2.x and the like) that you *WANT* to keep multiple versions around. However, that list should give you a starting point for checking if you have any other KDE 3.3 stuff around, and will show some other things you might have forgotten, as well. (I just ran it here, checking, for the first time in awhile, and among other things I see some old lm_sensors that I think are safely removable, and an old python, now that the new one has proven stable at least against portage, anyway.) Run revdep-rebuild after that to clean up the loose end dependencies left around, and little if anything should be broken, PROVIDED your original unmerge choices weren't insane. If worse comes to worse, remerging the affected app should fix things. (Here's another place FEATURES=buildpkg can come in rather handy. It's a very nice safety net to have! =8^) As for trying to link against a 32-bit binary libqd, you are correct, that's rather strange. Note that I don't have mplayer installed at all, only xinelib, which I use as the backend for kmplayer. (IIRC it still depends on mplayer, but I package.provided that, and configure it to use xine instead.) I read somewhere sometime ago that xinelib just seems to work for many folks that were previously jumping thru hoops to get mplayer working, and had found that to be the case back on (32-bit) Mandrake, so after having issues with 64-bit mplayer on Gentoo, rather than compromise and run the 32-bit version with proprietaryware binary-only codecs, I installed 64-bit xinelib, and it actually played far more than I expected it to, in 64-bit only mode, so that's what I've kept. (I'm assuming that means that most or all of the codecs it is using are open, that is open code reverse engineered or open spec, or 64-bit shared-object versions wouldn't have been available.) Maybe you'll find similar? Anyway, after removing the old kdelibs, I'd remerge the new version, and double-check (with readelf or the like) to ensure it is indeed trying to link against the 32-bit version. If so, that's a serious bug that needs filed, if it hasn't been already. As seems to happen frequently around here, I'm a bit out of my depth, again (<sigh>, but also <g>, because that means "a target rich environment" as they say, in terms of learning opportunities =8^). However, that would seem to indicate either that the 64-bit build is looking in 32-bit-land (lib32) when it shouldn't be, or that the *.la files are mixed up and in the wrong location, or both. In any case, it's a serious issue that /might/ apply to /other/ libraries as well, as we move over to a better multilib, creating who knows /what/ sort of havoc, so getting it bugged would seem a /very/ good idea. -- 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 in -- gentoo-amd64@g.o mailing list