KDE4 load libicui18n.so.38 not found - can create system crash!
David Southwell
Below is a script produced from a failed attempt to load kde4 on amd64.
Up until latest upgrades there were no problems.
Now loading from
#startx now produces thhe output shown from the script file.
The very wierd thing is that in the event of a second attempt to launch x
with startx the whole system crashes immediately.
So I am seeing two problems relating specifically to this report.
1. The primary failure which seems to be due to an inability to find
libicui18n.so.38.
2. The secondary question is why should a crash occur when a second attempt
is made to startx? This suggests a systematic failure of some kind.
My guess is the primary may be solveable by rebuilding icu and its
dependencies (quit a lot I believe!).
There seem to be some other problems revealed by this script which I do not
understand.
Comments would be appreciated.
Thanks in advance
david
_______________________________________________________
SCRIPT
_____________________________
Script started on Fri Dec 31 14:56:27 2010
You have mail.
%startx xauth: creating new authority file /home/david/.serverauth.32995
X.Org X Server 1.7.5
Release Date: 2010-02-16
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.2-RELEASE-p3 amd64
Current Operating System: FreeBSD dns1.vizion2000.net 7.2-RELEASE-p3 FreeBSD
7.2-RELEASE-p3 #0: Thu Aug 20 12:54:34 BST 2009
da...@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64
Build Date: 18 December 2010 11:28:21PM
Current version of pixman: 0.18.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 31 14:56:33 2010
(==) Using config file: "/etc/X11/xorg.conf"
failed to set mtrr: Invalid argument
record: RECORD extension enabled at configure time.
record: This extension is known to be broken, disabling extension now..
record: http://bugs.freedesktop.org/show_bug.cgi?id=20500
kbuildsycoca4 running...
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry Actions in
"ServiceMenus/krename_all_nonrec.desktop" is not compliant with XDG standard
(missing trailing semicolon).
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry Actions in
"ServiceMenus/krename_dir_rec.desktop" is not compliant with XDG standard
(missing trailing semicolon).
kbuildsycoca4(33106)/kdecore (services) KServicePrivate::init: The desktop
entry file "Graphics/ElectricEyes.desktop" has an empty mimetype!
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry MimeType in
".hidden/kommander.desktop" is not compliant with XDG standard (missing
trailing semicolon).
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry Categories
in "/usr/local/share/applications/gcalctool.desktop" is not compliant with
XDG standard (missing trailing semicolon).
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry MimeType in
"/usr/local/share/applications/xmms.desktop" is not compliant with XDG
standard (missing trailing semicolon).
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry Categories
in "/usr/local/share/applications/gretl.desktop" is not compliant with XDG
standard (missing trailing semicolon).
kbuildsycoca4(33106) KConfigGroup::readXdgListEntry: List entry Categories
in "/usr/local/share/applications/xsane.desktop" is not compliant with XDG
standard (missing trailing semicolon).
kbuildsycoca4(33106)/kdecore (services) KServicePrivate::init: The desktop
entry file "/usr/home/david/.local/share/applications/Shells.desktop" has
Type= "Application" but no Exec line
kbuildsycoca4(33106) KBuildServiceFactory::createEntry: Invalid Service :
"/usr/home/david/.local/share/applications/Shells.desktop"
kbuildsycoca4(33106) parseLayoutNode: The menu spec file contains a Layout
or DefaultLayout tag without the mandatory Merge tag inside. Please fix your
file.
startkde: Starting up...
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kded(36752)/kdeui (KIconLoader) KSharedDataCache::Private::mapSharedMemory:
Failed to establish shared memory mapping, will fallback to private memory
-- memory usage will increase
QMetaObject::invokeMethod: No such method
KUniqueApplication::loadCommandLineOptionsForNewInstance()
kbuildsycoca4 running...
Fetched layout groups from X server: layouts: ("us") variants:
("")
Fetched layout groups from X server: layouts: ("us") variants:
("")
kglobalaccel(43911)/kdeui (KIconLoader)
KSharedDataCache::Private::mapSharedMemory: Failed to establish shared
memory mapping, will fallback to private memory -- memory usage will
increase
QMetaObject::invokeMethod: No such method
KUniqueApplication::loadCommandLineOptionsForNewInstance()
QDBusObjectPath: invalid path ""
kcminit(44395)/kdeui (KIconLoader)
KSharedDataCache::Private::mapSharedMemory: Failed to establish shared
memory mapping, will fallback to private memory -- memory usage will
increase
kded(36752)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
QDBusConnection: name 'org.kde.kglobalaccel' had owner '' but we thought it
was ':1.5'
Could not open library ksmserver: Cannot load library
/usr/local/kde4/lib/libkdeinit4_ksmserver.so: (Shared object
"libicui18n.so.38" not found, required by "libpulse-mainloop-glib.so.0")
/libexec/ld-elf.so.1: Shared object "libicui18n.so.38" not found, required
by "libpulse-mainloop-glib.so.0"
startkde: Shutting down...
klauncher: Exiting on signal 1
kde3: not found
kde3: not found
startkde: Running shutdown scripts...
startkde: Done.
waiting for X server to shut down kded4: Fatal IO error: client killed
%exit
Script done on Fri Dec 31 14:57:58 2010
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Robert Huff
David Southwell writes:
> So I am seeing two problems relating specifically to this report.
> 1. The primary failure which seems to be due to an inability to find
> libicui18n.so.38.
I'm getting a number of porgrams suddenly reporting this
missing as well.
Robert Huff
Kurt Jaeger
> My guess is the primary may be solveable by rebuilding icu and its
> dependencies (quit a lot I believe!).
Yes, rebuilding devel/icu and it dependencies works.
I also deleted the stuff in /usr/local/lib/compat/, just to make it
sure it does not collect the wrong libicui18n.
/usr/local/lib/libicui18n.so.46.0 was installed by package icu-4.6
Hope this helps.
--
p...@opsec.eu +49 171 3101372 10 years to go !
David Southwell
> -----Original Message-----
> From: Robert Huff [mailto:rober...@rcn.com]
> Sent: 31 December 2010 07:46
> To: David Southwell
> Cc: freebs...@freebsd.org
> Subject: KDE4 load libicui18n.so.38 not found - can create
> system crash!
>
>
> David Southwell writes:
>
> > So I am seeing two problems relating specifically to this report.
> > 1. The primary failure which seems to be due to an
> inability to find
> > libicui18n.so.38.
>
> I'm getting a number of porgrams suddenly reporting
> this missing as well.
>
>
> Robert Huff
>
>
Hi Robert
I am just rebuilding pulseaudio to see if that fixes the primary problem on
this system. I am then going to rebuild ever4ything that depends upon
devel/icu (My huess is well over 200 ports!).
Could you possibly check that your devel/icu is up to date and then rebuild
any progtams that have show problems with libicu18n.so.38 and post your
results?
David
David Southwell
> -----Original Message-----
> From: owner-fre...@freebsd.org
> [mailto:owner-fre...@freebsd.org] On Behalf Of Kurt Jaeger
> Sent: 31 December 2010 07:50
> To: freebs...@freebsd.org
> Subject: Re: KDE4 load libicui18n.so.38 not found - can
> create system crash!
>
> Hi!
>
> > My guess is the primary may be solveable by rebuilding icu and its
> > dependencies (quit a lot I believe!).
>
> Yes, rebuilding devel/icu and it dependencies works.
>
> I also deleted the stuff in /usr/local/lib/compat/, just to
> make it sure it does not collect the wrong libicui18n.
>
> /usr/local/lib/libicui18n.so.46.0 was installed by package icu-4.6
>
> Hope this helps.
>
Sure does -- its good to feel one may be going in the right direction.
That leaves the serious issue of the system crash. In order to test results
I am having to shutdown and restart the system when startx fails once.!! NOT
GOOD!
david
David Southwell
> -----Original Message-----
> From: owner-fre...@freebsd.org
> [mailto:owner-fre...@freebsd.org] On Behalf Of David Southwell
> >
> > Hi!
> >
> > > My guess is the primary may be solveable by rebuilding
> icu and its
> > > dependencies (quit a lot I believe!).
> >
> > Yes, rebuilding devel/icu and it dependencies works.
> >
> > I also deleted the stuff in /usr/local/lib/compat/, just to make it
> > sure it does not collect the wrong libicui18n.
> >
> > /usr/local/lib/libicui18n.so.46.0 was installed by package icu-4.6
> >
> > Hope this helps.
Just adding to the mix - I have just started a rebuild of devel/icu and
reread the above. In /usr/local/lib/compat I find no libicu files -- ther
is however a collection in /usr/lical/lib/compat/pkg/. They are:
libicu-
data.so.38.1
data.so.40.0
data.so.40.1
data.so.46.0
i18n.so.38.1
i18n.so.40.0
i18n.so.40.1
i18n.so.46.0
io.so.38.1
io.so.46.0
le.so.38.1
le.so.40.0
le.so.40.1
le.so.46.0
lx.so.38.1
lx.so.46.0
test.so.46.0
tu.so.38.1
tu.so.46.0
uc.so.38.1
uc.so.40.0
uc.so.40.1
uc.so.46.0
Bearing in mind
#portupgrade -fr devel/icu is currently in hand what, if anything, needs to
be done with these files?
David
David Southwell
_____
From: Sergio de Almeida Lenzi [mailto:lenzi....@gmail.com]
Sent: 31 December 2010 08:46
To: David Southwell
Cc: 'Kurt Jaeger'; freebs...@freebsd.org
Subject: RE: KDE4 load libicui18n.so.38 not found - can create system crash!
for me, I solved this problem with this script, use: sh script
libicui18n.s0.38
it scans every lib in /usr/local for the string libicui18n.so.38
and than finds the package that has that lib,
finally it builds the ports that have that string.
=======================================
t=/tmp/$$
find /usr/local -name "*.so" | \
while read x
do
if grep $1 $x
then
pkg_info -qW $x >> $t
echo found in $x
fi
done
if [ -s $t ]
then
portmaster $(sort -u $t)
fi
rm -f $t
========================================
Seems a much more sensible approach than rebuilding all ports depending
upon icu. On my system there are 250 targets using portupgrade -fr devel/icu
My guess is your script would have considerably reduced the number of ports.
However I am going to let it complete now the run is underway.
Any ideas why one gets a crash on a second attempt to startx? For more info
see first posting in the thread.
Thanks
Sergio de Almeida Lenzi
libicui18n.s0.38
it scans every lib in /usr/local for the string libicui18n.so.38
and than finds the package that has that lib,
finally it builds the ports that have that string.
=======================================
t=/tmp/$$
find /usr/local -name "*.so" | \
while read x
do
if grep $1 $x
then
pkg_info -qW $x >> $t
echo found in $x
fi
done
if [ -s $t ]
then
portmaster $(sort -u $t)
fi
rm -f $t
========================================
_______________________________________________
David Southwell
>
> From: Sergio de Almeida Lenzi [mailto:lenzi....@gmail.com]
> Sent: 31 December 2010 08:46
> To: David Southwell
> Cc: 'Kurt Jaeger'; freebs...@freebsd.org
> Subject: RE: KDE4 load libicui18n.so.38 not found - can create system
> crash!
>
>
> libicui18n.s0.38
> it scans every lib in /usr/local for the string libicui18n.so.38
> and than finds the package that has that lib,
> finally it builds the ports that have that string.
>
> =======================================
> t=/tmp/$$
> find /usr/local -name "*.so" | \
> while read x
> do
> if grep $1 $x
> then
> pkg_info -qW $x >> $t
> echo found in $x
> fi
> done
> if [ -s $t ]
> then
> portmaster $(sort -u $t)
> fi
> rm -f $t
> ========================================
> upon icu. On my system there are 250 targets using portupgrade -fr
> devel/icu My guess is your script would have considerably reduced the
> number of ports. However I am going to let it complete now the run is
> underway.
>
> Any ideas why one gets a crash on a second attempt to startx? For more info
> see first posting in the thread.
>
with the system and startx loads kde4 as normal.
However I am left with this nagging concern about why a complete system crash
occured when following a first failure to load the second attempt caused an
immediate system crash.
So I am reposting the original script below.
Any ideas where to take this?
Thanks
David
_______________________________________________________
SCRIPT
_____________________________
Any ideas
Photographic Artist
Permanent Installations & Design
Creative Imagery and Advanced Digital Techniques
High Dynamic Range Photography & Official Portraiture
Combined darkroom & digital creations
& Systems Adminstrator for the vizion2000.net network