Ken Moffat wrote:
On Wed, Jun 04, 2008 at 08:35:38AM -0400, john q public wrote:
  
Hello all,

 I saw no mention of gdb in either the LFS 
or BLFS book. Is it
not a good thing to use?
    

 It's mentioned on the "other tools" page at the end of chapter 12
in BLFS.
  

 Yes, random faults can be *interesting* to track down.  
 As to using gdb, it depends on what you are trying to debug  but using it on a simple program should at least let you
know _where_ it is failing.  Of course, if you stripped the
libraries like the LFS book suggests, you've already made things
hard :-(

 Other things you haven't mentioned - using strace (not the obvious
tool for segfaults, but it might mention some odd results from
calls, which could explain why something is taking an unexpected
path through the code), and the various bug-tracking tools
(bugzilla or whatever at freedesktop.org and the major distros) may
help.

 In general, you need to get an insight into where it is blowing up,
and then use whatever is available to either find out why, or to find
an existing workaround.  Gdb is often the best way to find 'where',
but learning to use it productively is a task in itself.

ĸen
  
Thanks for advice about stripped libraries that has probably saved me some time. For the record I'm not actually
having problems with a "standard" package but have taken on a long "dead" project I picked up at sourceforge and I'm in the process of getting it down to just GTK+ and the new libMTP. When it doesn't segfault it seems to run nicely so I feel good considering I haven't been at it for long. I suspect its a non malloced pointer issue or
similar. So I plan on cleaning up the compiler warnings first as there arent many and I'm betting it'll fall out
when I see the code again.

Thanks Ken and Dan for the help I truly appreciate it.

John
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to