Boost logo

Boost :

Subject: [boost] [Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2012-10-25 10:56:33

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

How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do
something for GCC?


> (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++...
>>> 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. :)

Boost list run by bdawes at, gregod at, cpdaniel at, john at