Apache OpenOffice (AOO) Bugzilla – Issue 11343
full debug switch does not make sense
Last modified: 2003-03-11 18:16:07 UTC
644 nowadays will be compiled with full debug by default. IHMO this does not make sense, because * needed disk space is increaed dramaticly * you can't debug the office with less than 2 GB Ram.
It makes sense because this enables us to map pstack output (UNIX) or user mode dump (Windows) to source level debug info even for products installed at customer side. Diskspace increases: Yes that's true but not avoidable. It was not the intention to debug product builds but to enable mapable crash dumps.
This is not acceptable from an OOo development point of view. Most developers will not be able to allocate gigabytes of disk space for builds. I have three individual partions with 4 gig each for three different build types for various reasons, I can no longer support this because 4 gig is not enough for the standard build, this reduces my ability to support OOo. There are more than a few people who would be turned off by a 6 gig allocation just to build something, therefore you loose potential developers. THere must be a comprimise route like default build without gcc -g option, release build with -g and full debug build. Most developers will be targetting a single part of the tree not all of it and they can enable complete debugging for those specific parts vastly reducing their disk requirements.
from my point of view we do not need source level debug for getting detailed info from customers problems. I suggest to do this analysis on stack trace level and not with that detailed info.
Hi, FWIW, I agree 100% with Ken and Martin. PPC Linux will NOT be adding the -g since the addition of that switch greatly increases the size required for the build. If someone has a serious bug/problem: 1. the stack trace should help 2. if not, we should be able to recreate the bug in our own builds and create specific debug libs to help track it down 3. if not, we can still post a shared library (just look at stack trace) built with debugging for the user to add to create a more detailed backtrace for us. Besides I think the stripping we do to the binaries (depending on the flags passed to strip) will strip out this debug info as well resulting in only our own build trees being bloated with no real benefit. So FWIW: ppc linux will be building without it. BTW, The Blackdown project has in the past posted a full debug version of others to download who were having problems to help diagnose things. Perhaps a happy comprimise would be to have one Linux x86 fully debug binary available for each release that we e-mail the url to for people who have bugs too difficult to track down. Kevin
This feature is useful to analyze those issues you just cannot reproduce. OO.o used to crash occasionally. This has improved quiet a lot. But the goal needs to be to understand all crashes. I understand that we need to find a compromize during development time. But I am fully convinced that the final build (the one that goes online as a release to the public) needs to have full debug info available. Maybe we need to have an additional parameter that gets passed to make for these kind of production builds? - Joerg
As discussed in QTF default build mode will be changed to nonpro optimized without debug information.
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.