Bug 477095 - /etc/profile.d/kde4.sh sets incorrect KDE4_LIBDIR
Summary: /etc/profile.d/kde4.sh sets incorrect KDE4_LIBDIR
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kdelibs
Version: 9
Hardware: sparc64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: kde42
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-19 02:16 UTC by Dennis Gilmore
Modified: 2009-02-19 11:42 UTC (History)
7 users (show)

Fixed In Version: KDE 4.2.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-19 11:42:47 UTC
Type: ---
Embargoed:


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

Description Dennis Gilmore 2008-12-19 02:16:24 UTC
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-19 02:38:57 UTC
This should use kde4-config --path qtplugins instead of rpm --eval.

Comment 2 Kevin Kofler 2008-12-19 02:42:48 UTC
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-19 02:52:12 UTC
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-19 02:56:02 UTC
[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-19 02:59:15 UTC
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-19 03:05:29 UTC
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-19 03:09:14 UTC
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 17:23:21 UTC
Ping?

Comment 9 Rex Dieter 2009-02-06 17:45:42 UTC
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.