[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt
(2012/10/17 0:09), Matthew Chambers wrote:
On 10/15/2012 11:29 PM, Steven Watanabe wrote:
AMDG
On 10/15/2012 07:54 PM, Kohei Takahashi wrote:
Hi all,
Can anyone handle following two issues?
<runtime-debugging>on does nothing for libstdc++... https://svn.boost.org/trac/boost/ticket/4589
This is /not/ a trivial issue. It may be easy to do, but:
I understood about this is not trivial issue and I changed the subject.
a) _GLIBCXX_DEBUG was broken last time I tried it a few years ago. It won't work with all versions of gcc.
I've used it with 4.1.2 and it helped a lot to track down some mysterious failures. I don't know about old releases but recents seem to work well for me. Indeed, expects to work well and should work with all versions of gcc if define it by default.
b) Anything the changes the ABI of the compiled libraries needs careful consideration and must be documented. The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build.
Is it really that important that debug builds be ABI compatible between disparate builds? I think it's reasonable to EXPECT trouble when linking a debug build to precompiled libraries. That is certainly the case on Windows.
<define> is not propagated feature, that means to trigger unexpected link failure or ABI breaking. I think that using <runtime-debugging> make safely rather than <define>. I think it is better that provides propagated feature (as <runtime-debugging> or another) for such purpose at least.
c) <runtime-debugging>on is part of <variant>debug, but I don't think _GLIBCXX_DEBUG is a standard part of debug builds with gcc.
What is a "standard" debug build with gcc? Most people would probably say -g and -O0 but that doesn't provide any real debugging support.
I agree it's not trivial, but having a no-op runtime-debugging feature is cringe-worthy. It's as good as admitting that GCC (or rather, libstdc++) doesn't provide any "official" runtime debugging support which is unfair.
In the spirit of upcoming elections, count this as a vote for turning on _GLIBCXX_DEBUG. :)
On Thu, Oct 25, 2012 at 4:56 PM, Matthew Chambers <matt.chambers42@gmail.com> wrote:
I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list.
How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build."
How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC?
Why not create a new variant for this eh, variant? Olaf
On 25 October 2012 15:57 Matthew Chambers [mailto:matt.chambers42@gmail.com] wrote :-
How many would sacrifice ABI compatibility in order for <runtime- debugging>on to actually do something for GCC?
Would sort of vote +1/2 I do like having debug builds do any/all available runtime checks however I think that the lack of being able to "automagically" link to the correct lib would make this a pain using gcc. Using MSVC it's a treat - build all the variants of boost libraries that you want - stash 'em away somewhere and just use 'em without any worry - (ok often need to make sure that any dll versions used are known about by any installer being made). Without this think that the amount of tinkering with some products build system to get correct boost libs would mean I wouldn't want to use it very often. Its probably more straightforward than I think (environment variable pointing to different directories or some such) but changing the build for anything other than a totally trivial program always seems to be more work than I want it to be and so tend to avoid it if possible (irrespective of what system used for the build - be it scons, cmake, bjam or makefiles) (Would love to see some equivalent of #pragma comment( lib, ) behaviour with gcc though if anyone has any ideas!) Alex
On 25/10/12 16:56, Matthew Chambers wrote:
I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list.
How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build."
How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC?
Don't sacrifice ABI compatibility. Make a superdebug variant or something.
on Thu Oct 25 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
On 25/10/12 16:56, Matthew Chambers wrote:
I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list.
How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build."
How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC?
Don't sacrifice ABI compatibility. Make a superdebug variant or something.
+1. The runtime penalties could also be too steep for some programs, even when you're just debugging. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
participants (5)
-
Alex Perry -
Dave Abrahams -
Mathias Gaunard -
Matthew Chambers -
Olaf van der Spek