Bug 477095 - /etc/profile.d/kde4.sh sets incorrect KDE4_LIBDIR
/etc/profile.d/kde4.sh sets incorrect KDE4_LIBDIR
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kdelibs (Show other bugs)
9
sparc64 Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On: kde42
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-18 21:16 EST by Dennis Gilmore
Modified: 2009-02-19 06:42 EST (History)
7 users (show)

See Also:
Fixed In Version: KDE 4.2.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-19 06:42:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hack that lets kde start normally (720 bytes, patch)
2008-12-18 21:52 EST, Dennis Gilmore
no flags Details | Diff
clean patch to determine plugin path (1.11 KB, patch)
2008-12-18 22:09 EST, Dennis Gilmore
no flags Details | Diff

  None (edit)
Description Dennis Gilmore 2008-12-18 21:16:24 EST
Description of problem:
sparc64 systems have a 32 bit userland 

/etc/profile.d/kde4.sh contains

if [ -z "$QT_PLUGIN_PATH" ]; then
  KDE4_LIBDIR=`/bin/rpm --eval '%{?_kde4_libdir}%{!?_kde4_libdir:%{_libdir}}' 2>/dev/null`
  QT_PLUGIN_PATH=${KDE4_LIBDIR}/kde4/plugins && export QT_PLUGIN_PATH
fi

on sparc64 it evaluates to /usr/lib64  but everything is in /usr/lib  this probably occurs on ppc64 also  

Version-Release number of selected component (if applicable):

kdelibs-4.1.2-1.fc9.sparcv9

How reproducible:

always

Steps to Reproduce:
1. start kde
2.
3.
  
Actual results:
dbus connection failing

Expected results:

kde to start

Additional info:

if you run sparc32 startx you get a working kde as it runs as a 32 bit process.
Comment 1 Kevin Kofler 2008-12-18 21:38:57 EST
This should use kde4-config --path qtplugins instead of rpm --eval.
Comment 2 Kevin Kofler 2008-12-18 21:42:48 EST
Oh, and if that also does the wrong thing, then you probably need to fix RPM's ELF coloring. On ppc64 RPM will prefer the ppc(32) binary over the 64-bit one.

(IMHO this idea of defaulting to 32-bit is pretty broken, especially as hardware manufacturers consider it a "compatibility mode" only, but that's just my 2 eurocents.)
Comment 3 Dennis Gilmore 2008-12-18 21:52:12 EST
Created attachment 327406 [details]
hack that lets kde start normally

with the attached patch i can start kde normally
Comment 4 Dennis Gilmore 2008-12-18 21:56:02 EST
[root@ultram ~]# kde4-config --path qtplugins
/root/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
[root@ultram ~]# uname -m
sparc64


depends on the hardware.  sparc64 and ppc64 hardware the only thing you gain by having 64 bit userland is access to more than 4gb ram per process.

but running 64bit userland costs you in memory usage and load times.  all binaries are bigger and take longer to load.   you get access to all registers and cpu functionality in 32 bit mode.
Comment 5 Kevin Kofler 2008-12-18 21:59:15 EST
Looks like using kde4-config is the right solution then, I don't like your arch-specific hack at all (also because it doesn't solve the problem for ppc64, I wonder why we didn't get any bug report about that yet, does nobody use KDE 4 on a PPC with a 64-bit kernel?).
Comment 6 Kevin Kofler 2008-12-18 22:05:29 EST
Oh, and if the multi-component is a problem (I don't think it is though), we can use --install instead of --path, that will return only /usr/lib/kde4/plugins/.
Comment 7 Dennis Gilmore 2008-12-18 22:09:14 EST
Created attachment 327408 [details]
clean patch to determine plugin path

this is cleaner and worked for me
Comment 8 Steven M. Parrish 2009-02-06 12:23:21 EST
Ping?
Comment 9 Rex Dieter 2009-02-06 12:45:42 EST
Fixed, yes, in kde-4.2:

Fri Jan 09 2009 4.1.96-4
* kde.(sh|csh): cleanup QT_PLUGIN_PATH handling.

Note You need to log in before you can comment on or make changes to this bug.