Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4720E51A.3090401@rowe-clan.net>
Date: Thu, 25 Oct 2007 13:48:58 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: Use of /Fd option on Windows
References: <4720B29B.8060800@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE64380121F821@epmsa009.minsk.epam.com>
In-Reply-To: 
 <7BDB2168BEAEF14C98F1901FD2DE64380121F821@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

For dynamic libs, use /Fd to point to a DIFFERENT file name, because
that source-code .pdb is unrelated to the resulting binary .pdb that
results from link /debug /opt:ref (otherwise indistinguishable from
link /release but for massively useful information :-)  I've taken
to calling these /Fd"Release\libapr_src" where _src is a different
collection of pdb info from the libapr-1.pdb that corresponds to a dll.

For static libs, I've taken to compiling all the lib's sources into
a /Fd pdb named for the static lib, so that they move nicely together.
E.g for apr-1.lib static library, /Fd"Release\apr-1" gives us a nice
source-code pdb.

Once apr-1.lib+apr-1.pdb have been link /debug 'ed into a resulting
binary, neither is interesting anymore, so these are very much for the
library consumer.

Bill