On 04/13/2011 08:39 AM, David C. Rankin wrote: > Baho, All, > > I was working with the new Qt3 build on x86_64 and I ran into an > xsession crash that I need help identifying the cause. I have put the > .xsession-error, trinity-qt3 file list up at: > > http://www.3111skyline.com/dl/dt/trinity/err/newqt3/xsession-error-new-qt3.txt > > > http://www.3111skyline.com/dl/dt/trinity/err/newqt3/new-qt3-no-work-file-list.txt > > > I have reinstalled an older build of Qt3 and it works fine, so there > is something in the new build. The PKGBUILD is modeled after the one > you are using, but I have enabled the doc and examples. I have put the > PKGBUILD up here: > > http://www.3111skyline.com/dl/dt/trinity/err/newqt3/PKGBUILD-qt3-trinity > > Looking at the xsession-error file, the following jump out at: > > DCOP: register 'anonymous-1000' -> number of clients is now 4 > DCOP: 'anonymous-1000' now known as 'kwin' > kdeinit: Got EXEC_NEW 'kdesktop' from launcher. > DCOP: register 'kdesktop' -> number of clients is now 5 > DCOP: register 'anonymous-1001' -> number of clients is now 6 > DCOP: register 'anonymous-1002' -> number of clients is now 7 > DCOP: unregister 'anonymous-1002' > *** glibc detected *** kdesktop [kdeinit]: free(): invalid next size > (fast): 0x00000000008dda20 *** > ======= Backtrace: ========= > /lib/libc.so.6(+0x71b96)[0x7fed6bd43b96] > /lib/libc.so.6(cfree+0x6c)[0x7fed6bd4896c] > /usr/lib/libxcb.so.1(+0x9b64)[0x7fed68288b64] > /usr/lib/libxcb.so.1(xcb_wait_for_reply+0x124)[0x7fed682891c4] > /usr/lib/libX11.so.6(_XReply+0x10d)[0x7fed6c597b3d] > /usr/lib/libX11.so.6(XInternAtom+0xa4)[0x7fed6c581744] > /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN18KBackgroundManagerC1EP7QWidgetP10KWinModule+0x4e6)[0x7fed661bd516] > > /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktop8initRootEv+0x430)[0x7fed661add80] > > /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktopC1Ebb+0x4b3)[0x7fed661b2d23] > > /opt/trinity/lib/libkdeinit_kdesktop.so(kdemain+0x6b4)[0x7fed661947f4] > kdesktop [kdeinit][0x408728] > kdesktop [kdeinit][0x409f75] > kdesktop [kdeinit][0x40a866] > kdesktop [kdeinit](main+0xa64)[0x40c1c1] > /lib/libc.so.6(__libc_start_main+0xfd)[0x7fed6bcf0dcd] > kdesktop [kdeinit][0x4064b9] > ======= Memory map: ======== > <snip> > > DCOP aborting (delayed) call from 'anonymous-1001' to 'kdesktop' > DCOP: unregister 'kdesktop' > DCOP: unregister 'anonymous-1001' > KCrash: crashing... crashRecursionCounter = 2 > KCrash: Application Name = kdesktop path = <unknown> pid = 1002 > kdeinit: Got EXEC_NEW 'drkonqi' from socket. > kdeinit: PID 1001 terminated. > kdeinit: Got EXEC_NEW 'kicker' from launcher. > Could not load library! Trying exec.... > kdeinit: PID 1003 terminated. > <snip> > > dcop: error while loading shared libraries: libqt-mt.so.3: cannot open > shared object file: No such file or directory > [startkde] Shutting down Trinity... > kdeinit: terminate KDE. > klauncher: Exiting on signal 1 > DCOP: unregister 'anonymous-14951' > DCOP: unregister 'khotkeys' > DCOP: unregister 'kded' > DCOP: unregister 'anonymous-14950' > DCOP: unregister 'klauncher' > DCOPServer : slotShutdown() -> waiting for clients to disconnect. > DCOPServer : slotExit() -> exit. > [startkde] Running Trinity shutdown scripts... > [startkde] Trinity shutdown complete. > > I can't explain the first 2 error blocks, but the "dcop: error while > loading shared libraries: libqt-mt.so.3: cannot open shared object > file: No such file or directory" is self explanatory. However, if you > check the file list link above, libqt-mt.so.3 is there: > > 07:36 alchemy:~/tmp> grep libqt-mt.so.3 new-qt3-no-work-file-list.txt > /opt/qt/lib/libqt-mt.so.3 > /opt/qt/lib/libqt-mt.so.3.3 > /opt/qt/lib/libqt-mt.so.3.3.8 > > So, why is this file not being found? The path for the linker is not correct. What is in /etc/ld.so.conf.d and /etc/ld.so.conf The dynamic link loader can not find the file you need an entry into one of those files/directory with /usr/qt/lib You can look at /etc/trinity-kdelibs.conf as an example. It could also be that the dynamic link loader is looking to /opt/qt/lib64 Do you have a/anything in /opt/qt/lib64? This is what this part of the qt PKGBUILD is for. It fixes up the libraries on 64 bit machines. You could try adding that back in. I took that out because I am only on i686 at the moment, I havn't got "aroundtoit" installing a clean x86_64 arch install. I will at some time, as I just didn't want to fight the battle on both platforms at once. When I get TDE to run on i686 (most things working) I go for the x86_64. # [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${srcdir}/$pkgfqn/src/Makefile # [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${srcdir}/$pkgfqn/tools/designer/designer/Makefile # [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${srcdir}/$pkgfqn/tools/designer/editor/Makefile # [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${srcdir}/$pkgfqn/tools/assistant/lib/Makefile # [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${srcdir}/$pkgfqn/tools/designer/uilib/Makefile This is one of the reasons I wanted to put qt3 back into /usr. I don't have to mess to much with the library paths. Qt4 does own some files that has the same name as qt3 that's why the file error(s) occured when qt3 was placed in /usr. So I bumped it to /ust/qt3. When TDE is fully ported to QT4 this will be a mute point as qt3 get binned. Trinity runs just fine when everthing is compiled to live in /usr. Also you can kill off this in your PKGBUILD -docdir ${_prefix}/share/doc/qt \ -headerdir ${_prefix}/include/qt \ -plugindir ${_prefix}/lib/qt/plugins \ -datadir ${_prefix}/share/qt \ -translationdir ${_prefix}/share/qt/translations \ It is not needed. Try the latest qt3 PKGBUILD in my devel directory on your server, Not the one accessible on the http server. PS. the link from the devel directory to the web served directory is gone so I can't update what the http server has. You will need to remake the symlink.