Eclipse was a good choice Re: Developement under LFS/BLFS question
Simon Geard wrote: On Thu, 2008-06-05 at 07:35 -0400, john q public wrote: Very good suggestion! There is a plugin/environment for C/C++ for eclipse as well. Eclipse has always looked cool to me I just don't do any Java at this point so I left it on the back burner. But hooking gcc/gdb to this extension sounds like something worth fooling with. >From what I've heard, the Eclipse CDT extensions are decent enough - not as well integrated as the Java environment, but then, that's not exactly surprising. I've never used them, but wouldn't mind hearing how they work out for you... Simon. Just finished hooking up gdb to it and so far so good. The built-in editor looks decent and I've migrated the source I was trying to clean up to CDT/eclipse. It's building properly now and CDT has given me a lead to follow on the cause of the segfaults. Probably have more to say about it later but so far I'm fairly impressed and it looks like its worth getting to know well. Seems there's enough to work with that it could serve as a sort of cross platform VC++ John -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Eclipse was a good choice Re: Developement under LFS/BLFS question
john q public wrote: Just finished hooking up gdb to it and so far so good. The built-in editor looks decent and I've migrated the source I was trying to clean up to CDT/eclipse. It's building properly now and CDT has given me a lead to follow on the cause of the segfaults. Probably have more to say about it later but so far I'm fairly impressed and it looks like its worth getting to know well. Seems there's enough to work with that it could serve as a sort of cross platform VC++ John hmm, Code::Blocks, using WxWidgets is a C++ cross platform ide. no gui building tool in it though. For building a gui WxGlade is the most common used for it, though that requires both WxWidgets and WxGTK libs. [ WxPython, WxPerl [ cpan package so adding this is easy with perl ] and WxJava language bindings available also. ] All of WxWidgets is under a modified LGPL, Code::Blocks is GPL V3. so all open source. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Developement under LFS/BLFS question
On Thu, 2008-06-05 at 07:35 -0400, john q public wrote: Very good suggestion! There is a plugin/environment for C/C++ for eclipse as well. Eclipse has always looked cool to me I just don't do any Java at this point so I left it on the back burner. But hooking gcc/gdb to this extension sounds like something worth fooling with. From what I've heard, the Eclipse CDT extensions are decent enough - not as well integrated as the Java environment, but then, that's not exactly surprising. I've never used them, but wouldn't mind hearing how they work out for you... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Developement under LFS/BLFS question
Simon Geard wrote: On Wed, 2008-06-04 at 07:20 -0700, Dan Nicholson wrote: On Wed, Jun 4, 2008 at 5:35 AM, john q public [EMAIL PROTECTED] wrote: My REAL question is does anyone have advice on when its better to comb the source versus chasing problems with the debugger? I believe that Mr. Torvalds thinks debuggers are almost always the wrong thing and a waste of time vs. just thinking about the source. But everyone has their preference. I personally don't know gdb that well, so it's usually is faster for me to debug problems by reading the code. Varies with the bug. If I already have a fairly good idea what kind of problem it is, reading code is usually enough. More commonly though, I just know that the output of some big block of code is incorrect, and that's where a good debugger helps follow the inputs, making it easier to spot when some intermediary value looks wrong. Sure, you can theoretically do all the computations in your head. But really, if you've got good tools, why not let them do the hard part for you? Note - my coding is mostly in Java, using the excellent debugger built into the Eclipse IDE. I don't have very much experience of using gdb... Simon. Very good suggestion! There is a plugin/environment for C/C++ for eclipse as well. Eclipse has always looked cool to me I just don't do any Java at this point so I left it on the back burner. But hooking gcc/gdb to this extension sounds like something worth fooling with. Thanks, John -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Developement under LFS/BLFS question
Hello all, I've asked about IDEs in the past and there are a lot to choose from so for now I've put that off and just edit source without anything else. BUT now I'm running into segfaults and such (worse theyre sporadic so sometimes things mostly work other times everything grinds to a halt). I saw no mention of gdb in either the LFS or BLFS book. Is it not a good thing to use? I'll check hints and see if I find something there. My REAL question is does anyone have advice on when its better to comb the source versus chasing problems with the debugger? I know there's no right answer on that but I'd really appreciate some commentary. In actuality I've been a programmer for years and this has always been a tough choice. I did embedded for a while and was it amazing to plug in an ICE in place of the CPU and find right away that something on the board itself was defective. You'd never find something like that on your own because the code is written assuming a board with all the right values for the CPU. Chasing something caused by a faulty component can really leave you haunted. :-) Regards and thanks, John -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Developement under LFS/BLFS question
On Wed, Jun 04, 2008 at 08:35:38AM -0400, john q public wrote: Hello all, I've asked about IDEs in the past and there are a lot to choose from so for now I've put that off and just edit source without anything else. BUT now I'm running into segfaults and such (worse theyre sporadic so sometimes things mostly work other times everything grinds to a halt). 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. I'll check hints and see if I find something there. My REAL question is does anyone have advice on when its better to comb the source versus chasing problems with the debugger? I know there's no right answer on that but I'd really appreciate some commentary. In actuality I've been a programmer for years and this has always been a tough choice. I did embedded for a while and was it amazing to plug in an ICE in place of the CPU and find right away that something on the board itself was defective. You'd never find something like that on your own because the code is written assuming a board with all the right values for the CPU. Chasing something caused by a faulty component can really leave you haunted. :-) Yes, random faults can be *interesting* to track down. I'm assuming you are talking about problems with common packages in BLFS. If your box has recently started to segfault, consider if the power supply has become defective (if you are able, try swapping it with a different one), or perhaps you've added things and the power drain is now too much for the supply. If that doesn't sound familiar, at least try running memtest86+ (for old boxes, memtest86 is probably adequate) for a few hours to see if the memory is flakey. Of course, if you recently tweaked any settings in the bios, you might need to untweak them. If the segfaults also occur in packages which are part of LFS, maybe you've applied excessive optimisations to the system. As to using gdb, it depends on what you are trying to debug - trying to use it on the Xserver is nasty and left as an exercise for the reader, 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 -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Developement under LFS/BLFS question
On Wed, Jun 4, 2008 at 5:35 AM, john q public [EMAIL PROTECTED] wrote: Hello all, I've asked about IDEs in the past and there are a lot to choose from so for now I've put that off and just edit source without anything else. BUT now I'm running into segfaults and such (worse theyre sporadic so sometimes things mostly work other times everything grinds to a halt). I saw no mention of gdb in either the LFS or BLFS book. Is it not a good thing to use? gdb is a fine thing to use. I think it's mentioned briefly in the programming section. I have a half completed patch that adds strace and gdb to the book, but I never got around to finishing it. Building gdb is easy, but watch out on the install since it steps on parts of binutils if you don't do it right: ./configure --prefix=/usr make make -C gdb install My REAL question is does anyone have advice on when its better to comb the source versus chasing problems with the debugger? I believe that Mr. Torvalds thinks debuggers are almost always the wrong thing and a waste of time vs. just thinking about the source. But everyone has their preference. I personally don't know gdb that well, so it's usually is faster for me to debug problems by reading the code. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Developement under LFS/BLFS question
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
