[gentoo-amd64] Re: OpenOffice Problems

[Duncan]

Ãéþñãïò Áâñáìßäçò posted
<200511151204.54234.avramidg@×××××.com>, excerpted below,  on Tue, 15 Nov
2005 12:04:54 +0200:

> I did USE="-java" emerge openoffice-bin because i had some problems with java,
> emerged just fine.
>  But when I try to run ooffice it says
>  /usr/lib32/openoffice/program/soffice.bin: symbol lookup
> error: /emul/linux/x86/usr/lib/libkdecore.so.4: undefined symbol:
> _ZN6QImage15setMaxImageSizeERK5QSize
>
>  I re-emerged all the emul libraries in my system, but no luck. I also
> re-emerged kdelibs.
>  Any ideas?

OK, I don't have that particular library on my system, but an equery
(part of gentoolkit, very useful merge, if you don't have it already) for
the 64-bit version results in:

$equery b /usr/kde/3.5/lib64/libkdecore.so.4
[ Searching for file(s) /usr/kde/3.5/lib64/libkdecore.so.4 in *... ]
kde-base/kdelibs-3.5.0_rc1 (/usr/kde/3.5/lib64/libkdecore.so.4 -> libkdecore.so.4.2.0)

So... you were right, it's part of kdelibs in native-bitness land. 
However, remerging the 64-bit kdelibs isn't likely to do much for 32-bit
land.

I'd suggest running:

equery belongs -f libkdecore.*

on your system, and see what comes up.  It should list both the 32/64-bit
versions, along with the *.la files, since the -f=full-regex, along with
the packages they come from (or try the emul path and specific file,
without the -f of course, to only get it for that file). At least then
you'll know what emul-lib package owns the issue causing library.

Perhaps a revdep-rebuild will help?  (Run it with the usual -p for
pretend mode, first, to see what it'll do.)  If not, you'll at least be a
step closer than before, and can file a bug or whatever, or try reverting
to an earlier version of the culprit package.

BTW, iso-2022-jp, Japanese charset?  It looks more Greek/Russian, here. 
Is PAN bugging on me?

BTW2, /something/ is, as even with it changed, I'm still getting the error,

ERROR: line 1, column 8010768 uses a character not specified in charset
"ISO-2022-jp" -- possibly change your charset in "More Headers" to
"iso-2022-jp" instead?

Hmm... interesting, the original content-type header say US-ASCII, the
from header indicates 8859-7/Greek (not unusual from what I understand of
i18n of mail, tho i18n isn't  my strong point), so how'd PAN come up with
2020-jp? I'll try 8859-7, I guess.

BTW3, interesting host name, there.  "Trantor"?  Another Asimov fan?

-- 
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