On Fri, 2014-07-25 at 12:13 -0400, Alan Conway wrote: > On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote: > > ... > > My vote would be to default to the most optimised/operational-quality
I agree with this, but I strongly believe that operational-quality includes debugging symbols. Operational systems *will* have problems and without debug symbols somewhere, core dumps are next to useless. I think it's important to note that systems vendors usually ship debugging symbols - I know that Red Hat do, Microsoft do, and I'm pretty sure that Sun used to too. Now these debugging symbols are usually not kept in the executables themselves, but in separate files which are split apart in the product build. For RHEL/Fedora there are -debuginfo packages that give you source and symbols. > ... > > If the RelWithDebInfo is exactly as fast then that's probably OK, but if To be honest I wouldn't have chosen the exact default flags for the different builds that the CMake developers have chosen - these are (for gcc) Debug: -g Release: -O3 -DNDEBUG RelWithDebInfo: -O2 -g -DNDEBUG MinsizeRel: -Os -DNDEBUG I think it makes almost no sense to build without debugging info, so I'd change Release to "-O3 -g -DNDEBUG". Although -O3 often makes optimisations that confuse a debugger at least you'd get a stack trace. My personal favourite would be "-Os -g" - Often, paradoxically, (though you need to benchmark) optimising for space speeds up your code more than optimising for speed. Philosophically I don't think you should ever turn assertions off either, so I'd not include -DNDEBUG. In any case, I think the difference between -O2 and -O3 is small. But I strongly assert that debug symbols are an important end-user deployment feature, for when things go wrong (and of course they will eventually). > > I'm honest I believe that the default should really be to build > > something that a user might want to ship in an operational > > mission-critical system and I'm not personally keen on the idea of > > shipping with debug symbols or anything else that could potentially > > increase an attack vector. I fail to see how shipping symbols to code that is open source changes the attack surface even if you subscribe to "security by obscurity". Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
