havent entirely figured out where this is coming from, but on my machines i'm getting an LDPATH inserted into my environment: vapier@vapier-m 0:0 ~ $ echo $LDPATH /usr/kde/3.5/lib: looking at the processes: init(1)─┬─kdeinit(2061)───konsole(2113)───bash(769)───pstree(8469) │ │ └─kdm(1819)─┬─X(1847) └─kdm(1848)───startkde(2008)───kwrapper(2075) kdm/X/startkde do not have it, but kwrapper/kdeinit/and all their children do root@vapier-m 0:0 ~ # strings /proc/1819/environ | grep LDPATH root@vapier-m 0:1 ~ # strings /proc/1847/environ | grep LDPATH root@vapier-m 0:1 ~ # strings /proc/1848/environ | grep LDPATH root@vapier-m 0:1 ~ # strings /proc/2008/environ | grep LDPATH root@vapier-m 0:1 ~ # strings /proc/2075/environ | grep LDPATH LDPATH=/usr/kde/3.5/lib: root@vapier-m 0:0 ~ # strings /proc/2061/environ | grep LDPATH LDPATH=/usr/kde/3.5/lib: root@vapier-m 0:0 ~ # strings /proc/2113/environ | grep LDPATH LDPATH=/usr/kde/3.5/lib:
A lot of crud was in my LDPATH var inside KDE until I switched gcc a couple of times and logged out and in again in KDE. Now it just contains what you noted here: /usr/kde/3.5/lib:
this issue has existed for pretty much all of kde-3.5.x that i can remember, so it shouldnt block a 3.5.10 stabilization as it isnt a regression
LDPATH is inserted in /usr/kde/3.5/bin/startkde for no reason whatsoever... It's in Gentoo specific part of that file so it was intentionally added at some point. With RPATH all the way, it should not be needed though. I'll remove it and see what happens.
I don't see this issue anymore with KDE 4.3.3, can you verify? As KDE 3.5.10 masked for removal, this should be closed...
`strings /proc/*/environ | grep LDPATH` no longer returns any hints, so let's assume it's fixed. if it crops up again, i'll notice fairly quickly as it breaks software i use daily.