[gentoo-amd64] AMD64 linking issues.

[gentoo-amd64] AMD64 linking issues.

[Tres Melton]

I have been working on that darned libcom_err.so.3 error that has
plagued many of us (including those w/ x86).  I have just posted
something to the forum and wanted to post it here to to get reactions
from x86-64 users on my speculation in the last paragraph.  Anyway:
----------------------------------------------------------------
http://forums.gentoo.org/viewtopic-p-2574850.html#2574850

Well it seems that sys-libs/com_err-1.38 and sys-libs/ss-1.38 were
released today. I dutifully upgraded my system (along with some other
packages) and everything seems to have gone okay. Upon conclusion I
retried revdep-rebuild and came up with the same error: 

rm /root/.revdep-rebuild*.?_* ; revdep-rebuild 
... 
Checking dynamic linking consistency... 
broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so (requires
libgdk_imlib.so.1) 
broken /usr/kde/3.3/lib/kde3/kio_http.so (requires libcom_err.so.3) 
done. 
(/root/.revdep-rebuild.3_rebuild) 
... 
All prepared. Starting rebuild... 
emerge --oneshot =app-emulation/emul-linux-x86-gtklibs-2.1 
... 
Build finished correctly. Removing temporary files... 

I don't have the same symptoms as others (w/ Samba) and I'm
sure /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so is related
to mplayer32-bin but for some reason revdep-rebuild doesn't even attempt
to fix /usr/kde/3.3/lib/kde3/kio_http.so. 

"equery belongs /usr/kde/3.3/lib/kde3/kio_http.so" failed to return
anything but "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.
----------------------------------------------------------------
Thoughts?

Best Regards,
-- 
Tres

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: AMD64 linking issues.

[Duncan]

Tres Melton posted <1121406115.808.429.camel@thor.tres.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@gentoo.org mailing list

Re: [gentoo-amd64] AMD64 linking issues.

[Edward Killips]

On Jul 15, 2005, at 1:41 AM, Tres Melton wrote:


> I have been working on that darned libcom_err.so.3 error that has
> plagued many of us (including those w/ x86).  I have just posted
> something to the forum and wanted to post it here to to get reactions
> from x86-64 users on my speculation in the last paragraph.  Anyway:
> ----------------------------------------------------------------
> http://forums.gentoo.org/viewtopic-p-2574850.html#2574850
>
>
That library is supplied by the MIT kerberos package and in no longer  
built by default.
I had to manually build the kerberos package and force libcom_err.so. 
3 to build.
This resolved all of the linking errors.

> Well it seems that sys-libs/com_err-1.38 and sys-libs/ss-1.38 were
> released today. I dutifully upgraded my system (along with some other
> packages) and everything seems to have gone okay. Upon conclusion I
> retried revdep-rebuild and came up with the same error:
> rm /root/.revdep-rebuild*.?_* ; revdep-rebuild
> ...
> Checking dynamic linking consistency...
> broken /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so  
> (requires
> libgdk_imlib.so.1)
> broken /usr/kde/3.3/lib/kde3/kio_http.so (requires libcom_err.so.3)
> done.
> (/root/.revdep-rebuild.3_rebuild)
> ...
> All prepared. Starting rebuild...
> emerge --oneshot =app-emulation/emul-linux-x86-gtklibs-2.1
> ...
> Build finished correctly. Removing temporary files...
>
> I don't have the same symptoms as others (w/ Samba) and I'm
> sure /emul/linux/x86/usr/lib/gtk/themes/engines/libpixmap.so is  
> related
> to mplayer32-bin but for some reason revdep-rebuild doesn't even  
> attempt
> to fix /usr/kde/3.3/lib/kde3/kio_http.so.
>
> "equery belongs /usr/kde/3.3/lib/kde3/kio_http.so" failed to return
> anything but "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.
> ----------------------------------------------------------------
> Thoughts?
>
> Best Regards,
> -- 
> Tres
>
> -- 
> gentoo-amd64@gentoo.org mailing list
>
>

Ed

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] AMD64 linking issues.

[Olivier Crete]

On Fri, 2005-15-07 at 12:54 -0400, Edward Killips wrote:
> On Jul 15, 2005, at 1:41 AM, Tres Melton wrote:
> 
> 
> > I have been working on that darned libcom_err.so.3 error that has
> > plagued many of us (including those w/ x86).  I have just posted
> > something to the forum and wanted to post it here to to get reactions
> > from x86-64 users on my speculation in the last paragraph.  Anyway:
> > ----------------------------------------------------------------
> > http://forums.gentoo.org/viewtopic-p-2574850.html#2574850
> >
> >
> That library is supplied by the MIT kerberos package and in no longer  
> built by default.
> I had to manually build the kerberos package and force libcom_err.so. 
> 3 to build.
> This resolved all of the linking errors.

This library is now in the separate com_err package.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] AMD64 linking issues.

[Edward Killips]

I have the com_err package installed and I tried revdep-rebuild. I  
still had libcom_err.so.3 errors. The only way I found to fix the  
errors was to force the kerberos package to build libcom_err. The  
library supplied by the com_err package not being recognized bye the  
packages that require libcom_err.so.3.

Ed
On Jul 15, 2005, at 1:10 PM, Olivier Crete wrote

>> On Jul 15, 2005, at 1:41 AM, Tres Melton wrote:
>>
>>
>>
>>
>>> I have been working on that darned libcom_err.so.3 error that has
>>> plagued many of us (including those w/ x86).  I have just posted
>>> something to the forum and wanted to post it here to to get  
>>> reactions
>>> from x86-64 users on my speculation in the last paragraph.  Anyway:
>>> ----------------------------------------------------------------
>>> http://forums.gentoo.org/viewtopic-p-2574850.html#2574850
>>>
>>>
>>>
>>>
>> That library is supplied by the MIT kerberos package and in no longer
>> built by default.
>> I had to manually build the kerberos package and force libcom_err.so.
>> 3 to build.
>> This resolved all of the linking errors.
>>
>>
>
> This library is now in the separate com_err package.
>
> -- 
> Olivier Crête
> tester@gentoo.org
> Gentoo Developer
> x86 Security Liaison
>
>
> -- 
> gentoo-amd64@gentoo.org mailing list
>
>



-- 
gentoo-amd64@gentoo.org mailing list