Re: [Boost-bugs] [Boost C++ Libraries] #4349: Autolinking against debug STLport

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4349: Autolinking against debug STLport
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-07-25 06:42:12

#4349: Autolinking against debug STLport
  Reporter: eckhardt@… | Owner: johnmaddock
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: config
   Version: Boost Development Trunk | Severity: Problem
Resolution: invalid | Keywords:

Comment (by eckhardt):

 I guess my misunderstanding was that there are 'd' and 'g', which mean the
 same thing but one for the program being built and the other for the
 support libraries it uses. What I thought was that the 'g' was only
 intended to activate additional diagnostics (checked iterators etc).
 Looking at the
 docs] for this makes it a bit clearer, even though these docs refer to an
 undocumented 'n' flag in the example, too. How about something like this
 concerning the documentation

  * g debug/diagnostic runtime libraries (release if not present).
  * y debug/diagnostic Python runtime (release if not present).
  * d debug/diagnostic build (release if not present).

 The above makes clearer that the three all control the same thing but for
 separate parts of the code.

 What I'm wondering though is why that separation exists. I personally
 haven't seen the need to use different settings for the program being
 built and the libraries it links. Worse, MSVC assumes you don't want to do
 that either. What I do want now and then is to disable additional
 diagnostics, because those tend to slow down things a lot, especially on
 remotely-debugged embedded targets, which is what I work with most.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:03 UTC