[gentoo-amd64] Re: AMD64 linking issues.

[Duncan]

Tres Melton posted <1121406115.808.429.camel@×××××××××.org>, excerpted
below,  on Thu, 14 Jul 2005 23:41:55 -0600:

> "equery belongs kio_http.so" 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 fix_libtool_files.sh 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
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list