Re: default -g ??!?
On 11/20/2010 1:05 PM, MK wrote: I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. The black box on an airplane doesn't get much use, either. That's no reason to strip (*cough*) it out, though is it? That would make figuring out the cause of a crash much more difficult. I don't need to connect the dots for you, do I? much, much rather have it work in as streamlined a manner day to day, *by default*, then if I run into a problem, I can build "CFLAGS=-g" to diagnose. That's great when your problems are easily reproducible. One of the goals of a good software development process is to find and fix all the easily reproducible bugs before binaries ship to customers. If not on first release, certainly soon after. Having achieved that, you're left with nothing but blue-moon crashers, and there's nothing better for diagnosing the cause of such things than a core dump. Sometimes, though, a core dump doesn't tell you anything when you copy it to your development station. You need to debug the problem in place. If the debugging symbols are already present on the production system, life is easy. (Well, as easy as debugging ever gets.) If not, now you have to figure out how to build debug binaries in a state exactly like how they shipped to that one customer, who, if you have an agile development process, probably has a different version than almost any other site, simply depending on when their system was last upgraded. (If you can always upgrade every customer to the latest version just to debug a problem, you must work in a very different business environment than I find myself in.) If the rebuilt debug binaries don't match the shipped binaries, the core dump will be useless, because it will have pointers that refer to incorrect locations in the new program text. No doubt you have a good version numbering system so you can figure out how to rebuild those binariesgiven maybe an hour or so. An hour you probably don't have, because the customer is calling every ten minutes wanting to know when you'll have their system back up. An hour you could have spent debugging the problem in situ using the debugging symbols you had the forethought to leave in the shipping binaries. If I put a device in your car that ran the battery down and lowered the gas mileage, the purpose of which was to diagnose problems *when there aren't any*, then said you should leave it on all the time anyway, what would you think? Bad analogy. Debugging symbols don't affect a program when it's sitting there not running. You can't usefully compare this to a fictional car device that runs the battery down when the car isn't running. Such a device would necessarily take power when the car is running, and conservation of energy being the inviolable law it is, it will reduce your gas mileage slightly. (So does turning on the headlights, but you wouldn't advocate leaving them off at night to improve gas mileage.) The correct analogy is volume and weight: such a device takes room under the dash somewhere and makes the car slightly heavier, even when the car isn't running. Big deal. Debugging symbols take a bit of cheap disk space, they take a bit more cheap bandwidth to download, and they might possibly cause an extra disk seek or two as the program loader skips over the executable sections holding the unused debugging symbols. Big deal here, too. I understand the argument that by always using the -g version, you can avoid having complications whereby the exe compiled without debugging symbols may demonstrate problems the -g does not. However, by again letting this exception set the rule, you are condemning all software to run wastefully. If storage space and CPU time were the only considerations, every program would still be hand-coded in assembly language. Ever since computers came down out of the multimillion dollar stratosphere, human costs have usually swamped storage and computation costs. So, we have not only debugging symbols in production binaries, but also very high-level language compilers, managed memory runtimes, and vast, powerful, and wasteful third-party code libraries. These things all make programming easier, so programs cost less. The tradeoff being, we can no longer get a word processor, OS, and the document being edited to fit into 48 KB. If you really want to return to those days, they're still selling cheap, working Apple ][+es on eBay. Before you make your choice, you might want to listen to an old timer's recollections that such crude word processors cost about $220 in today's money. For that, you'd get a product that does less than Microsoft's Wordpad. (Or Apple's TextEdit, or KDE's KWord, or...) This old-timer remembers add-on packages costing more than the word
Re: default -g ??!?
The reason why users are helpless without debugging symbols is if a program crashes, all they can look at are the machine registers at the state of the crash. This is completely useless for figuring out why the program crashed, or getting help from another hacker to figure out why it crashed.
Re: default -g ??!?
On Sun, 21 Nov 2010 10:07:31 +0900 Miles Bader wrote: > MK writes: > > If you say so, then I guess I am imagining things ;) I have never > > given the issue much thought until now, I suppose I need to do a bit > > more research on the issue. > > Indeed, it's often a good idea to do the research _before_ posting > flames and rants... Yes. On the other hand, in my defence, GNU's online docs for make: http://www.gnu.org/software/make/manual/make.html which I sited earlier after searching for "debugging symbols", do not make a mature attempt to explain the issue at all and instead just use inflammatory phrases like "Users who don't mind being helpless can strip the executables later if they wish," and "Devil-may-care users can use the install-strip target to do that". No further explanation. Is this how I'm supposed to learn about Coding Standards? Via jokes and threats of some inexplicable bogey-man? If every piece of documentation related to this issue is just as flippant and patronizing, maybe it's no surprise I had to learn this in a mail list discussion. On the other hand, if there were even one sentence under "target all" justifying the default, such as, "Debugging symbols do not affect performance, and are not loaded into memory during normal use" instead of offhand references to the Devil, etc, this all could have been avoided. $0.02. Anyway, all apologies and thanks everyone for taking interest and a bit of time with me here. I have been a bit paranoid with the packaging because I want to see things done right, and understand the whys and wherefores. Excuse my previous extraneous paragraphs as "debugging symbols" ;) Lucky I left them in or I'd still be in the dark... -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
MK writes: > If you say so, then I guess I am imagining things ;) I have never > given the issue much thought until now, I suppose I need to do a bit > more research on the issue. Indeed, it's often a good idea to do the research _before_ posting flames and rants... -miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))
Re: default -g ??!?
MK writes: > Ah, it's because of GNU make: No it's not. > "By default, the Make rules should compile and link with -g, so that > executable programs have debugging symbols. Users who don't mind being > helpless can strip the executables later if they wish." > > Nice, flexible software it ain't. That isn't anything GNU make does, it's a _recommendation_ for Makefile writers. Automake, accordingly follows that recommendation, since it's a higher-level too than make, and tries to provide sensible defaults (whereas GNU make has no default compiler options). -Miles -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin.
Re: default -g ??!?
On Sat, 20 Nov 2010 14:21:27 -0600 (CST) Bob Friesenhahn wrote: > Under a normal operating system (i.e. perhaps not Plan 9, I am not > sure) the debug symbols are separate from the executable text so that > the OS will never read the debug symbol area while it is loading the > program. This means that there should be no performance difference. If you say so, then I guess I am imagining things ;) I have never given the issue much thought until now, I suppose I need to do a bit more research on the issue. -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
* MK wrote on Sat, Nov 20, 2010 at 09:55:51PM CET: > > Maybe so, and maybe not. But regardless: it makes more sense to have > the default *appropriate for general use*, rather for a distro packager > (who's work I do appreciate!). Otherwise, I have to put a note in the > INSTALL: "To accommodate the constraints of distro package systems, you > will have to use a configure option or strip your binaries if you do > not want debugging symbols slowing you down". Just tell them to 'make install-strip' rather than 'make install'. Please show numbers and glibc version to prove that your vim really loads slower when not stripped, you can use time vim -c :q the runtime loader does not map the debug sections so it should not have any impact. Besides, disk space is cheap nowadays, for excessive debug symbol sizes on sane systems like GNU/Linux one should file compiler/linker bugs. Cheers, Ralf
Re: default -g ??!?
On Sat, 20 Nov 2010 14:17:14 -0600 (CST) Bob Friesenhahn wrote: > The vast majority of Linux users install from binary packages, or via > source-based install systems which assure that appropriate build > options are applied. Very few build by hand and install under > /usr/local. True, but while I do not track binary downloads from debian, I do track source downloads from my site. Also, I get some feedback from users. Because versions of the project are currently in debian "unstable" and "testing" repos (which are necessary before it can be qualified "stable"), I am positive that *most* of my users are people who download and build from the source. Basically, I don't think source users should count as "second class citizens" here. > Those that do are likely to read the standard INSTALL > file and therefore know what to do. Maybe so, and maybe not. But regardless: it makes more sense to have the default *appropriate for general use*, rather for a distro packager (who's work I do appreciate!). Otherwise, I have to put a note in the INSTALL: "To accommodate the constraints of distro package systems, you will have to use a configure option or strip your binaries if you do not want debugging symbols slowing you down". I know that historically, that has been the practice, and I am arguing against the grain. > Since you found that gvim loads much quicker after it has been > stripped, I must assume that you are using the Plan 9 OS rather than > Linux. No, linux. I build vim because I have yet to see a distro package that is configured the way I want it (and no, the "vim-everything" packages do not actually contain everything). Generally I just use apt or yum, but for some particular things like this (or for projects such as my own, which are not available as binaries for every distro), I source build. Also, if you are using a small or offbeat linux distribution, there's surely a lot of software that simply is not available for it in binary, but that can easily be built from source. MK -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010, MK wrote: I mention this in my other email (about gvim, and that a -g exe will load noticeably slower than one without debug symbols). I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. Under a normal operating system (i.e. perhaps not Plan 9, I am not sure) the debug symbols are separate from the executable text so that the OS will never read the debug symbol area while it is loading the program. This means that there should be no performance difference. Perhaps you have a problem with your system or should be using 'vim' rather than 'gvim'? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: default -g ??!?
On Sat, 20 Nov 2010, MK wrote: Justifications WRT to distro packaging issues, however, seem much more reasonable. However, my conundrum is that I do not think this is a good default for people who build from source: years ago, when I was a new linux user and used to build stuff from source a lot, I was in the habit of stip-all'ing. Now I only source build for particular things, and I suppose I got out of this habit for a while and forgot about it. So I was surprised this morning to recognize that most of the binaries in my /usr/local had debugging symbols! And after stripping *, I noticed that gvim loads much quicker, heh-heh. The vast majority of Linux users install from binary packages, or via source-based install systems which assure that appropriate build options are applied. Very few build by hand and install under /usr/local. Those that do are likely to read the standard INSTALL file and therefore know what to do. Things are likely different for Plan 9 users due to substantially dimished support for binary packages for that OS. Since you found that gvim loads much quicker after it has been stripped, I must assume that you are using the Plan 9 OS rather than Linux. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: default -g ??!?
On Sat, 20 Nov 2010 17:31:32 + Roger Leigh wrote: > What actual problems are the debugging symbols causing you? > What is the wrong with the default? I mention this in my other email (about gvim, and that a -g exe will load noticeably slower than one without debug symbols). I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. Yes, I know you can optionally strip, but again this is has the exception make the rule. It just ain't as user friendly that way. > Most users are unaware if they are running stripped or unstripped > binaries, but when a user runs into problems, it's nice to have > unstripped binaries around for diagnostic purposes. So who cares that for who knows how long I have been tapping my fingers for 3-4 seconds waiting for my unstripped gvim to load?? I'd much, much rather have it work in as streamlined a manner day to day, *by default*, then if I run into a problem, I can build "CFLAGS=-g" to diagnose. If I put a device in your car that ran the battery down and lowered the gas mileage, the purpose of which was to diagnose problems *when there aren't any*, then said you should leave it on all the time anyway, what would you think? I understand the argument that by always using the -g version, you can avoid having complications whereby the exe compiled without debugging symbols may demonstrate problems the -g does not. However, by again letting this exception set the rule, you are condemning all software to run wastefully. > For Debian at least, we want unstripped binaries by default. We'll > do the stripping later. There is a reason for this. We provide > "-dbg" packages, which nowadays contain detached debugging symbols. > The dh_strip program handles this as already mentioned. Well, point taken, and certainly the stuff in my /usr/bin has been stripped by the distro. Terrific -- but as I said in the other email, this means you, the distro rep, are potentially setting policies for source built software (or forcing developers to maintain one for source downloads, one for debian, one for redhat, etc.) I have yet to discuss this with my packager, but if it is no good to say, "Well, we're the experts here: is it so hard for you to add -g to CFLAGS when you package?" because this would be incompatible with Debian systems or automation, then the Debian system has a design flaw in it, and someone saying to me "just put a note in your README" is, in effect, a work-around for *your* short sighted laziness (no offence intended). It's almost a form of imperialism, if you get my drift ;) How does it fit in with the GNU philosophy of user empowerment vs. "proprietary" policy making? > Having unstripped binaries is contrary to all these goals. Note that > this is not unique to Debian; Okay, so to stretch the analogy: one imperialist nation follows the example of another, so this justifies it? Methinks "the emperor wears no clothes" here. MK -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010 12:13:38 -0500 Paul Smith wrote: > This chapter has no relationship to any default BUILT INTO or REQUIRED > by GNU make; in fact there IS NO default value for CFLAGS built into > GNU make: Hmm, well it seems to via autotools. But since this is not inescapable (which is what I first took this to mean, not being a big "make" user), no big deal. Sorry again for over-reacting. > Of course you can do what you like, but I should point out that the > recommendations from the GNU people are the best practices resulting > from decades of producing and using free software products. If I were > you I'd take advantage of that experience. I have every respect for GNU, but the justification used in that document is just patronizing: implying that normal users will be left "helpless" or that it represents a "devil-may-care" attitude. I have been programming long enough to recognize that is someone's opinion, and not a general truth. Dare I say that presenting it so strongly is a little "unprofessional"? Justifications WRT to distro packaging issues, however, seem much more reasonable. However, my conundrum is that I do not think this is a good default for people who build from source: years ago, when I was a new linux user and used to build stuff from source a lot, I was in the habit of stip-all'ing. Now I only source build for particular things, and I suppose I got out of this habit for a while and forgot about it. So I was surprised this morning to recognize that most of the binaries in my /usr/local had debugging symbols! And after stripping *, I noticed that gvim loads much quicker, heh-heh. Point being: while users of the source can opt for this (if they know), it just seems like a bad policy to by default leave them with a product that needlessly wastes a considerable amount of memory and may not perform as well as it could. I believe most of my users do build from source (and often could be new to the process), so it is not very satisfying for me to "add a note to the README", etc, in order to accommodate distro packaging. It seems to me that since the packagers *in general* should be considered more expert, the onus should be on them to "./configure CFLAGS=[our flags]". Obviously this is against the grain, but I do not really want to kowtow to a "Goliath rules David" type extortion whereby the distros say, your default build *must* contain debugging symbols. I suppose that might mean having to maintain a slightly different package just for them; no big deal, but still I think a poor compromise consequential of bad policy. MK -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On Sat, Nov 20, 2010 at 10:36:34AM -0500, MK wrote: > Ah, it's because of GNU make: > > "By default, the Make rules should compile and link with -g, so that > executable programs have debugging symbols. Users who don't mind being > helpless can strip the executables later if they wish." > > Nice, flexible software it ain't. > > This is an assbackward policy. The idea that general, non-programmer > users will be "helpless" without debugging symbols is completely > absurd. What actual problems are the debugging symbols causing you? What is the wrong with the default? > If and when you do need debugging symbols, it should be easy to opt > *for* them. Instead, I am left with the choice of leaving them in by > default, or having to use "strip", making it impossible to add them. Automake already provides an "install-strip" target for just this purpose. Most users are unaware if they are running stripped or unstripped binaries, but when a user runs into problems, it's nice to have unstripped binaries around for diagnostic purposes. It's also contrary to the defaults, and what most people would expect, given that pretty much every other automake-using package does the opposite of what you want! For Debian at least, we want unstripped binaries by default. We'll do the stripping later. There is a reason for this. We provide "-dbg" packages, which nowadays contain detached debugging symbols. The dh_strip program handles this as already mentioned. In the future, we may end up taking a similar path to Ubuntu and automatically produce .ddebs (debug .deb packages) containing the stripped debug info for every single package built, or even allow direct download of symbols from a central database. Having unstripped binaries is contrary to all these goals. Note that this is not unique to Debian; all distributions want to have debug symbols for end-user diagnostics, and we don't want to ask the user to recompile with debug symbols enabled--they would then not be using the same binaries, which might not exhibit the same behaviour. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: default -g ??!?
On Sat, 2010-11-20 at 10:36 -0500, MK wrote: > Ah, it's because of GNU make: > > "By default, the Make rules should compile and link with -g, so that > executable programs have debugging symbols. Users who don't mind being > helpless can strip the executables later if they wish." > > Nice, flexible software it ain't. That's a recommendation about the GNU standard way to create makefiles. It's in a chapter called "Makefile Conventions" and the introductory sentence, which is just a paragraph or two above the section quoted above, says "All *GNU* programs *should* have the following targets in their Makefiles" (emphasis added). This chapter has no relationship to any default BUILT INTO or REQUIRED by GNU make; in fact there IS NO default value for CFLAGS built into GNU make: ~$ env -i make -pf/dev/null | grep -- -g # This program built for x86_64-pc-linux-gnu make: *** No targets. Stop. ~$ env -i make -pf/dev/null | grep CFLAGS make: *** No targets. Stop. LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c Of course you can do what you like, but I should point out that the recommendations from the GNU people are the best practices resulting from decades of producing and using free software products. If I were you I'd take advantage of that experience. -- --- Paul D. Smith Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: default -g ??!?
On Sat, 20 Nov 2010 16:51:48 +0100
Ralf Wildenhues wrote:
> > > Maybe there is a way to do this via autoconf?
> >
> > Yes, you can place:
> >
> > CFLAGS=""
> >
> > at the beginning of your configure.ac, after AM_INIT_AUTOMAKE but
> > before AC_PROG_CC.
> >
> > This will prevent your configure from allowing user-specified CFLAGS
> > overrides, but you will get what you want.
>
> : ${CFLAGS=}
>
> gets you both.
>
That does work (${CFLAGS=-O2}, which is fine as a default). Also,
if the user does specify flags, the -O2 default is not used, which makes
it better than my hack.
Thanks much!
--
"The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010 10:36:34 -0500 MK wrote: > If and when you do need debugging symbols, it should be easy to opt > *for* them. Instead, I am left with the choice of leaving them in by > default, or having to use "strip", making it impossible to add them. Sorry if that seemed like a rant. Anyway, I have managed to get that functionality by inserting this into the configure script from autoconf: CFLAGS=-O2" "$CFLAGS Giving make a default to use if no flags are present, and also making it possible for the user to add "CFLAGS=-g" if they wish. Please excuse my ignorance and frustration ;) -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
* Raphael 'kena' Poss wrote on Sat, Nov 20, 2010 at 04:47:00PM CET:
> Op 20 nov 2010, om 16:36 heeft MK het volgende geschreven:
> > Maybe there is a way to do this via autoconf?
>
> Yes, you can place:
>
> CFLAGS=""
>
> at the beginning of your configure.ac, after AM_INIT_AUTOMAKE but before
> AC_PROG_CC.
>
> This will prevent your configure from allowing user-specified CFLAGS
> overrides, but you will get what you want.
: ${CFLAGS=}
gets you both.
Re: default -g ??!?
Op 20 nov 2010, om 16:36 heeft MK het volgende geschreven: > Maybe there is a way to do this via autoconf? Yes, you can place: CFLAGS="" at the beginning of your configure.ac, after AM_INIT_AUTOMAKE but before AC_PROG_CC. This will prevent your configure from allowing user-specified CFLAGS overrides, but you will get what you want. Cheers -- k
Re: default -g ??!?
Ah, it's because of GNU make: "By default, the Make rules should compile and link with -g, so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish." Nice, flexible software it ain't. This is an assbackward policy. The idea that general, non-programmer users will be "helpless" without debugging symbols is completely absurd. If and when you do need debugging symbols, it should be easy to opt *for* them. Instead, I am left with the choice of leaving them in by default, or having to use "strip", making it impossible to add them. Maybe there is a way to do this via autoconf? -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010 15:31:01 +0100 Ralf Wildenhues wrote: > Hello, > > * MK wrote on Fri, Nov 19, 2010 at 08:10:25PM CET: > > Since I could not find a way to prevent the project being built -g, > > and there is no need for this. > > ./configure CFLAGS=-O2 That does not make sense for a few reasons: 1) I am not asking for a way for the user to configure with their own flags. I am not the user, I am the author, I am writing the makefile, I think this is clear in the original post. I would like the package to build without debugging symbols. I already have CFLAGS declared in the makefile. 2) Compiling -O2 does not "cancel" -g anyway, you can compile "gcc -g -O2" and *both flags* will be used. 3) -O2 is part of the default anyway. When I make I get "gcc [my makefile flags] -g -O2", etc. If I add -O2 to my flags, then -O2 appears twice. How can I remove -g? MK -- "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: default -g ??!?
On 20/11/10 06:10, MK wrote: I have a FOSS project distributed by debian, and for quite I've been using this in the Makefile.am under install-data-am: -strip --strip-all $(bindir)/executable Since I could not find a way to prevent the project being built -g, and there is no need for this. Use dh_strip However, I have a new release and my packager at debian is now saying they do not want strip used in makefiles. How can I prevent -g from being used? The normal debian packages are stripped by dh_strip, or not when the debug-symbols debs are made. Therefore, the debian packager wants control over that. Therefore, you don't need to worry about stripping.
Re: default -g ??!?
Hello, * MK wrote on Fri, Nov 19, 2010 at 08:10:25PM CET: > Since I could not find a way to prevent the project being built -g, and > there is no need for this. ./configure CFLAGS=-O2 See 'info Autoconf "C Compiler"'. For C++ use CXXFLAGS etc. Cheers, Ralf
