Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
[ No need to CC me, btw, despite the evil the BTS does to Reply-To ] On Sat, 2002-08-17 at 23:14, Marcus Brinkmann wrote: You might want to add a warning that this needs to be tested. Some packages, like glibc or the Hurd, can not be built without optimization (for example because of inline functions not being inlined). Right; that's why I just said the minimum optimization, and not no optimization at all. As for me personally, I have made peace with -O2 code. stepi is your friend ;) You are a sick man :)
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
This would lose a feature that I find valuable: usually, recompiling a package with the debug option will generate a binary whose symbols are compatible with the normal packaged binary. I have used this several times to chase down hard-to-find library compatibility bugs, or to interpret core-files from crashes that are difficult to reproduce. For that matter, there are also Heisenbugs to consider: some bugs only appear in the optimized version, not the un-optimized. Compiling the debugging version with different optimization flags would make tracking down these bugs needlessly difficult. For what it's worth, I have never had a problem with debugging optimized code. The line numbers sometimes jump around a bit, but always in a predictable way. -- Richard Braakman I sense a disturbance in the force As though millions of voices cried out, and ran apt-get. (Anthony Towns about the Debian 3.0 release)
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, 18 Aug 2002, Richard Braakman wrote: This would lose a feature that I find valuable: usually, recompiling a package with the debug option will generate a binary whose symbols are compatible with the normal packaged binary. I have used this several times to chase down hard-to-find library compatibility bugs, or to interpret core-files from crashes that are difficult to reproduce. For that matter, there are also Heisenbugs to consider: some bugs only appear in the optimized version, not the un-optimized. Compiling the debugging version with different optimization flags would make tracking down these bugs needlessly difficult. I suggest we add the noopt option, then. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
Please see also my comments in #113525. Ian.
Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, 2002-08-18 at 15:45, Ian Jackson wrote: Please see also my comments in #113525. I personally have no strong opinion on this, really. Whoever wrote the Rationale: part of this section obviously disagrees with you, though. Maybe machines are fast enough today in general that it isn't as much of an issue.
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, 2002-08-18 at 05:46, Richard Braakman wrote: For that matter, there are also Heisenbugs to consider: some bugs only appear in the optimized version, not the un-optimized. Compiling the debugging version with different optimization flags would make tracking down these bugs needlessly difficult. Right. I sort of guessed someone might raise this issue, but I wasn't sure how often it would come up in practise. I then propose the following patch. --- debian-policy-3.5.6.1/policy.sgml 2002-03-14 13:17:48.0 -0500 +++ debian-policy-3.5.6.1.hacked/policy.sgml2002-08-18 18:06:50.0 -0400 @@ -5357,34 +5357,63 @@ Debugging symbols are useful for error diagnosis, investigation of core dumps (which may be submitted by users in bug reports), or testing and developing the software. - Therefore it is recommended to support building the package - with debugging information through the following interface: - If the environment variable ttDEB_BUILD_OPTIONS/tt - contains the string ttdebug/tt, compile the software - with debugging information (usually this involves adding the - tt-g/tt flag to ttCFLAGS/tt). This allows the - generation of a build tree with debugging information. If - the environment variable ttDEB_BUILD_OPTIONS/tt contains - the string ttnostrip/tt, do not strip the files at - installation time. This allows one to generate a package - with debugging information included.footnote - p - Rationale: Using tt-g/tt by default causes wasted - CPU cycles since the information is stripped away - anyway; this can have a significant impact on the - efficiency of the autobuilders. Having a standard way - to build a debugging variant also makes it easier to - build debugging bins and libraries since it provides a - documented way of getting this type of build; one does - not have to manually edit ttdebian/rules/tt or - ttMakefile/tts. - /p - /footnote + For this reason, it is recommended to support the + standardized environment variable ttDEB_BUILD_OPTIONS/tt. + This variable can contain several flags to change how a + package is compiled. + /p + p + taglist + tagdebug/tag + item + p + If this string is present in ttDEB_BUILD_OPTIONS/tt, + then ensure that the package is compiled with whatever + additional information is necessary for debugging. For + programs written in the C language, this usually means + adding tt-g/tt to the ttCFLAGS/tt environment + variable. + /p + /item + tagnoopt/tag + item + p + The presence of this string means that the package + should be complied with the minumum possible amount of + optimization. For C programs, this usually implies + adding tt-O0/tt to ttCFLAGS/tt. Some programs + might fail to build or run at this level of + optimization; it may be necessary to use tt-O1/tt. + /p + /item + tagnostrip/tag + item + p + This string implies that the debugging symbols should + not be stripped from the binary during installation, so + that debugging information may be included in the + package. + /p + /item + /taglist + /p + p + Rationale: Using tt-g/tt by default causes wasted + CPU cycles since the information is stripped away + anyway; this can have a significant impact on the + efficiency of the autobuilders. Having a standard way + to build a debugging variant also makes it easier to + build debugging bins and libraries since it provides a + documented way of getting this type of build; one does + not have to manually edit ttdebian/rules/tt or + ttMakefile/tts. + /p + p The following makefile snippet is an example of how one may test for either condition; you will probably have to massage this example in order to make it work for your package. example compact=compact -CFLAGS = -O2 -Wall +CFLAGS = -Wall INSTALL = install INSTALL_FILE= $(INSTALL) -p-o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 @@ -5394,12 +5423,16 @@ ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif +ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) +CFLAGS += -O0 +else +CFLAGS += -O2 +endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif
Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, Aug 18, 2002 at 06:18:45PM -0400, Colin Walters wrote: On Sun, 2002-08-18 at 15:45, Ian Jackson wrote: Please see also my comments in #113525. I personally have no strong opinion on this, really. Whoever wrote the Rationale: part of this section obviously disagrees with you, though. Maybe machines are fast enough today in general that it isn't as much of an issue. I was given the impression by a buildd operator a while back that it was not an issue for our autobuilders, although I wouldn't swear to it. Perhaps one of those people is reading. -- Colin Watson [EMAIL PROTECTED]
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, Aug 18, 2002 at 11:52:54PM +0100, James Troup wrote: Yes, but it's complete and utter crap; it was then and still is now. Ben ran a buildd on vore which is one of the faster buildds, but I've run both vore and some of our slower (arm, m68k) buildds and I can guarantee you that the additional time incurred by using '-g' is so insignificant it's insulting to have to even discuss it. The whole -g thing really ought to be fixed; it snuck in AFAICS/R bypassing the proper policy procedure, and is, in any event, entirely bogus. I concur with not forcing maintainers to omit -g. I'd concur with strongly recommending including it, in fact. I don't omit it with XFree86 and I'll be damned if I'm about to start. It's too convenient to be able to hop into my build tree and send someone an unstripped binary with debugging symbols. I'm not giving that up without a fight. I don't have a strong opinion on what -O should be. Simply being able to get a worthwhile backtrace from a core file is so many light years ahead of what we currently support by default (and what Policy purports to mandate) that arguing over the relative merits of stepi versus nexti seems insignificant to me. (BTW, someone's mailer is a complete piece of crap. What the F is up with mangling the subject line like that?) -- G. Branden Robinson| You don't just decide to break Debian GNU/Linux | Kubrick's code of silence and then [EMAIL PROTECTED] | get drawn away from it to a http://people.debian.org/~branden/ | discussion about cough medicine. pgpgA28QGBh4D.pgp Description: PGP signature
Processed: Re: Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
Processing commands for [EMAIL PROTECTED]: severity 113525 wishlist Bug#113525: DEB_BUILD_OPTIONS=debug example in policy is unhelpful Severity set to `wishlist'. merge 157131 113525 Bug#113525: DEB_BUILD_OPTIONS=debug example in policy is unhelpful Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug Merged 113525 157131. retitle 157131 [PROPOSAL] Rework DEB_BUILD_OPTIONS section Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
severity 113525 wishlist merge 157131 113525 retitle 157131 [PROPOSAL] Rework DEB_BUILD_OPTIONS section thanks On Sun, 2002-08-18 at 18:52, James Troup wrote: I can guarantee you that the additional time incurred by using '-g' is so insignificant it's insulting to have to even discuss it. I kind of suspected so, but not having access to authoritative data I didn't want to try to change two things at once. Well, here's an updated patch which combines both then. I also removed some old cruft about a.out and -N. Any seconds? --- debian-policy-3.5.6.1/policy.sgml 2002-03-14 13:17:48.0 -0500 +++ debian-policy-3.5.6.1.hacked/policy.sgml2002-08-18 20:07:11.0 -0400 @@ -5332,13 +5332,21 @@ /p p - Generally the following compilation parameters should be used: + By default, when a package is being built, it any binaries + created should include debugging information, as well as + being compiled with optimization. You should also turn on + as many reasonable compilation warnings as possible; this + makes life easier for porters, who can then look at build + logs for possible problems. For the C programming language, + this implies the following compilation parameters should be + used: example compact=compact CC = gcc -CFLAGS = -O2 -Wall # sane warning options vary between programs +CFLAGS = -O2 -g -Wall # sane warning options vary between programs LDFLAGS = # none install -s # (or use strip on the files in debian/tmp) - /example/p + /example + /p p Note that by default all installed binaries should be stripped, @@ -5346,60 +5354,66 @@ prgninstall/prgn, or by calling prgnstrip/prgn on the binaries after they have been copied into ttdebian/tmp/tt but before the tree is made into a - package./p + package. + /p p - The tt-N/tt flag should not be used. On tta.out/tt - systems it may have been useful for some very small - binaries, but for ELF it has no good effect./p - - p - Debugging symbols are useful for error diagnosis, - investigation of core dumps (which may be submitted by users - in bug reports), or testing and developing the software. - Therefore it is recommended to support building the package - with debugging information through the following interface: - If the environment variable ttDEB_BUILD_OPTIONS/tt - contains the string ttdebug/tt, compile the software - with debugging information (usually this involves adding the - tt-g/tt flag to ttCFLAGS/tt). This allows the - generation of a build tree with debugging information. If - the environment variable ttDEB_BUILD_OPTIONS/tt contains - the string ttnostrip/tt, do not strip the files at - installation time. This allows one to generate a package - with debugging information included.footnote - p - Rationale: Using tt-g/tt by default causes wasted - CPU cycles since the information is stripped away - anyway; this can have a significant impact on the - efficiency of the autobuilders. Having a standard way - to build a debugging variant also makes it easier to - build debugging bins and libraries since it provides a - documented way of getting this type of build; one does - not have to manually edit ttdebian/rules/tt or - ttMakefile/tts. - /p - /footnote + Although binaries in the build tree should be compiled with + debugging information by default, it can often be difficult + to debug programs if they are also subjected to compiler + optimization. For this reason, it is recommended to support + the standardized environment + variable ttDEB_BUILD_OPTIONS/tt. This variable can + contain several flags to change how a package is compiled + and built. + /p + p + taglist + tagnoopt/tag + item + p + The presence of this string means that the package + should be complied with the minumum possible amount of + optimization. For C programs, this usually implies + adding tt-O0/tt to ttCFLAGS/tt. Some programs + might fail to build or run at this level of + optimization; it may be necessary to use tt-O1/tt. + /p + /item + tagnostrip/tag + item + p + This string implies that the debugging symbols should + not be stripped from the binary during installation, so + that debugging information may be included in the + package. + /p +
