Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 92333 invoked from network); 30 Oct 2007 18:25:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Oct 2007 18:25:10 -0000 Received: (qmail 15541 invoked by uid 500); 30 Oct 2007 18:24:58 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 15524 invoked by uid 500); 30 Oct 2007 18:24:58 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 15507 invoked by uid 99); 30 Oct 2007 18:24:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 11:24:58 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Farid_Zaripov@epam.com designates 217.21.63.3 as permitted sender) Received: from [217.21.63.3] (HELO EPMSA009.epam.com) (217.21.63.3) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 18:25:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js Date: Tue, 30 Oct 2007 20:24:40 +0200 Message-ID: <7BDB2168BEAEF14C98F1901FD2DE6438012AC4AB@epmsa009.minsk.epam.com> In-Reply-To: <47276EBE.2060500@rowe-clan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js Thread-Index: AcgbHV2Ozbi6imw8Qn2o97hb4tFKbwAAuklg References: <20071025174022.141271A9832@eris.apache.org> <4726486A.2020109@roguewave.com> <472650CE.5040403@rowe-clan.net> <7BDB2168BEAEF14C98F1901FD2DE64380122014E@epmsa009.minsk.epam.com> <47276EBE.2060500@rowe-clan.net> From: "Farid Zaripov" To: X-Virus-Checked: Checked by ClamAV on apache.org > -----Original Message----- > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]=20 > Sent: Tuesday, October 30, 2007 7:50 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r588290 -=20 > /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js >=20 > > 2. in dynamic builds the source pdb and the binary pdb both > > generating in OutDir using the single file with the name > > libstdxx.pdb. >=20 > This one is more problematic. Source and Binary .pdb's are=20 > two different file formats, you've corrupted the one creating=20 > the other. I don't think so. >From http://support.microsoft.com/kb/121366 ----------------------- By default, when you build projects generated by the Visual Workbench, the compiler switch /Fd is used to rename the .PDB file to .PDB. Therefore, you will have only one .PDB file for the entire project. When you run makefiles that were not generated by the Visual Workbench, and the /Fd is not used with /Zi, you will end up with two .PDB files: * VCx0.PDB (where "x" refers to the major version of the corresponding Visual C++, either "2" or "4"), which stores all debugging information for the individual .OBJ files. It resides in the directory where the project makefile resides. * .PDB, which stores all debugging information for the resulting .EXE file. It resides in the \WINDEBUG subdirectory. Why two files? When the compiler is run, it doesn't know the name of the .EXE file into which the .OBJ files will be linked, so the compiler can't put the information into .PDB. The two files store different information. Each time you compile an .OBJ file, the compiler merges the debugging information into VCX0.PDB. It does not put in symbol information such as function definitions. It only puts in information concerning types. One benefit of this is that when every source file includes common header files such as , all the typedefs from these headers are only stored once, rather than in every .OBJ file. When you run the linker, it creates .PDB, which holds the debugging information for the project's .EXE file. All debugging information, including function prototypes and everything else, is placed into .PDB, not just the type information found in VCX0.PDB. The two kinds of .PDB files share the same extension because they are architecturally similar; they both allow incremental updates. Nevertheless, they actually store different information. ----------------------- As I understand the source and binary pdb files store the different information, but may be combined in the single pdb file since the format for the both pdb files is the same and both pdb's supports merging the changes without corrupting the other data during the incremental updates. So I think first we need to decide whether the information from the source pdb is needed to the library users in dynamic builds or not? - If no, then we can generate the source pdb in IntDir with the default name (this is the same that revert the patch for dynamic builds). - If yes, then we can use the single pdb file in OutDir, or generate two pdb files libstdxx.pdb and libstdxx_src.pdb both in OutDir. > You might want to deploy the source pdb as=20 > $(IntDir)/stdlibxx_src.pdb - which is as temporary as any of=20 > the object files in the build. But - if you tweak one file=20 > and recompile, you won't have problems with the resulting=20 > $(OutDir)/stdlibxx.pdb losing any context from the previous=20 > .pdb for the modules that aren't rebuilt. >=20 > > So you propose to revert the patch only for dynamic builds? >=20 > Don't revert, you were on the right track :) I'd just take=20 > this one step further as I mentioned above. Farid.