On Wed, Jul 23, 2008 at 5:32 PM, buyoppy <buyoppy@xxxxxxxxxxx> wrote: > (I forgot to fix subject, so I resent this message again. > I'm sorry.) >> Date: Tue, 22 Jul 2008 11:52:40 +0100 >> From: "Simos Xenitellis" >> <simos.lists@xxxxxxxxxxxxxx> >> Subject: Re: How to debug Gnome (newbie question)? >> To: buyoppy <buyoppy@xxxxxxxxxxx> >> Cc: gnome-list@xxxxxxxxx >> Message-ID: >> >> > <598e9210807220352s6ac5d363v5b905c25610c6cb9@xxxxxxxxxxxxxx> >> Content-Type: text/plain; charset=UTF-8 >> >> On Mon, Jul 21, 2008 at 6:35 PM, buyoppy >> <buyoppy@xxxxxxxxxxx> wrote: >> > I'm using Debian etch. These days my Gnome >> windows >> > frequently freeze when it is going to be closed. >> How can I >> > let Gnome output error log to inspect what's >> happening? I >> > couldn't find out any clue in Gnome guides. >> > Could you give my any advice? >> >> Hi, >> >> You can find some debugging information in the file >> ~/.xsession-errors >> >> In addition, if you run these programs from the >> terminal, you normally >> get some extra messages. >> >> If you want to start reporting bugs at >> http://bugzilla.gnome.org/ it >> is good to make sure you have a standard system >> (fresh installation or >> installation with no invasive changes in the GNOME >> desktop). You can >> find existing bug reports so you can see if some >> issues are already >> reported. >> >> For every GNOME application, you can run them with >> >> file-roller --help >> >> You will notice other options, such as "--sync", >> which helps when debugging. >> >> You can also install the debugging support packages >> for the core GNOME >> libraries, so that any stack traces you get, will >> have more precise >> information, that will help to find the source or >> report to GNOME >> Bugzilla. >> For example, the GTK+ library comes from the >> libgtk2.0 package, and by >> installing the "-dbg" version (here, >> libgtk2.0-0-dbg), your stack >> traces will be more informational. >> >> For more information see >> http://live.gnome.org/Bugsquad/ >> >> Simos >> >> >> ------------------------------ > Thank you very much for your kind advice. > Actually I have another related question. I installed the > latest version of glib-2.0, etc. from tarball in order to > build some simulation library(libswarm). Latest version of > glib locates at /usr/local/lib. Since then Gnome becomes > to freeze, I think. > I don't know how to resolve such a problem: I want use > some application or library which requires the latest > version of fundamental library(like glib). On the other > hand, older version of that library which was installed > from package still remains at /usr/lib. That is, there > exists two different version of the same library on the > system. How can I use safely latest version at > /usr/local/lib for some app/lib without bothering older > version at /usr/lib to work for other existing packages? > I've been stucked at this problem for a few years. Could > you give me any enlightenment? > I'm sorry for my quite long question. Thanks in advance. You can bypass a library on demand using the LD_LIBRARY_PATH variable. If you want to run "mysimulation" with your new glib, open a Terminal and type export LD_LIBRARY_PATH=/usr/local/lib Then, verify that "mysimulation" actually bypasses the system glib and uses the freshly installed one, ldd /usr/local/bin/mysimulation ... libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x00007fc0b90aa000) ... If you get a line like that, then you are ready to run "mysimulation" with the new glib. Obviously, these settings of environment variables will be lost when you close the Terminal. If for some reason you want to keep them, you can edit /etc/environment and add there. Simos http://simos.info/blog/ _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
