You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stdcxx.apache.org by fa...@apache.org on 2007/10/25 19:40:21 UTC
svn commit: r588290 -
/incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Author: faridz
Date: Thu Oct 25 10:40:21 2007
New Revision: 588290
URL: http://svn.apache.org/viewvc?rev=588290&view=rev
Log:
2007-10-25 Farid Zaripov <fa...@epam.com>
* projectdef.js (projectCreateVCProject): Generate .pdb file
in $(OutDir) instead of $(IntDir). Use common .pdb file
instead of two (compiler's and linker's).
Modified:
incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Modified: incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
URL: http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js?rev=588290&r1=588289&r2=588290&view=diff
==============================================================================
--- incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js (original)
+++ incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js Thu Oct 25 10:40:21 2007
@@ -411,6 +411,23 @@
var allMacros = prjMacros.concat(cfgMacros);
+ var OutFile = this.OutFile != null ?
+ ReplaceMacros(this.OutFile, allMacros) :
+ "$(OutDir)\\" + PrjName + ext;
+
+ var IngoreLibs = "";
+ if (confInfo.dll)
+ {
+ IngoreLibs = confInfo.debug ? "msvcprtd.lib" : "msvcprt.lib";
+ }
+ else
+ {
+ if (confInfo.mt || NOSTCRT)
+ IngoreLibs = confInfo.debug ? "libcpmtd.lib" : "libcpmt.lib";
+ else
+ IngoreLibs = confInfo.debug ? "libcpd.lib" : "libcp.lib";
+ }
+
var compiler = conf.Tools.Item("VCCLCompilerTool");
if (null != compiler)
{
@@ -423,6 +440,7 @@
if (null != this.PrepOpts)
compiler.GeneratePreprocessedFile = this.PrepOpts;
compiler.DebugInformationFormat = debugEnabled;
+ compiler.ProgramDataBaseFileName = changeFileExt(OutFile, "pdb");
compiler.SuppressStartupBanner = true;
compiler.WarningLevel = warningLevel_3;
setProperty(compiler.Detect64BitPortabilityProblems, false);
@@ -486,28 +504,17 @@
linker.AdditionalOptions = LDFLAGS + " " +
(null != this.LnkOpts ? this.LnkOpts : "");
- linker.LinkIncremental = linkIncrementalNo;
- linker.SuppressStartupBanner = true;
- linker.GenerateDebugInformation = true;
if (null != this.Libs)
linker.AdditionalDependencies = this.Libs;
- if (confInfo.dll)
- {
- linker.IgnoreDefaultLibraryNames =
- confInfo.debug ? "msvcprtd.lib" : "msvcprt.lib";
- }
- else
- {
- if (confInfo.mt || NOSTCRT)
- linker.IgnoreDefaultLibraryNames =
- confInfo.debug ? "libcpmtd.lib" : "libcpmt.lib";
- else
- linker.IgnoreDefaultLibraryNames =
- confInfo.debug ? "libcpd.lib" : "libcp.lib";
- }
-
+ linker.LinkIncremental = linkIncrementalNo;
+ linker.SuppressStartupBanner = true;
+ linker.GenerateDebugInformation = true;
+ // use the compiler's .pdb
+ linker.ProgramDatabaseFile = "";
+ linker.IgnoreDefaultLibraryNames = IngoreLibs;
linker.SubSystem = this.SubSystem;
+
if (confInfo.debug)
{
linker.OptimizeReferences = optReferencesDefault;
@@ -519,12 +526,7 @@
linker.EnableCOMDATFolding = optFolding;
}
- if (this.OutFile != null)
- linker.OutputFile = ReplaceMacros(this.OutFile, allMacros);
- else
- linker.OutputFile = "$(OutDir)\\" + PrjName + ext;
-
- linker.ProgramDatabaseFile = changeFileExt(linker.OutputFile, "pdb");
+ linker.OutputFile = OutFile;
if (this.Type != typeApplication)
linker.ImportLibrary = changeFileExt(linker.OutputFile, "lib");
@@ -537,10 +539,8 @@
linker.AdditionalOptions = this.LibOpts;
librarian.SuppressStartupBanner = true;
- if (this.OutFile != null)
- librarian.OutputFile = ReplaceMacros(this.OutFile, allMacros);
- else
- librarian.OutputFile = "$(OutDir)\\" + PrjName + ".lib";
+ librarian.IgnoreDefaultLibraryNames = IngoreLibs;
+ librarian.OutputFile = OutFile;
}
if (null != this.PreLinkCmd)
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Farid Zaripov wrote:
>> As they say, it's combined into the output .pdb, but in
>> general the src pdb contains information useless to anyone
>> except the object linker, so it is bloated.
Agreed. Fixed thus: http://svn.apache.org/viewvc?rev=590686&view=rev
A fun way to test 'for free' without loading up a ton of visual studio
onto a given machine (e.g. a QA/test box) is to use WinDbg;
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
this will help validate that .pdb's are usable.
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, October 30, 2007 8:48 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> Farid Zaripov wrote:
> >
> > 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.
>
> As they say, it's combined into the output .pdb, but in
> general the src pdb contains information useless to anyone
> except the object linker, so it is bloated.
Agreed. Fixed thus: http://svn.apache.org/viewvc?rev=590686&view=rev
> The single-pdb
> is not a good solution for release builds where the .pdb will
> be shipped.
Farid.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Farid Zaripov wrote:
>
> 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.
As they say, it's combined into the output .pdb, but in general the src
pdb contains information useless to anyone except the object linker, so
it is bloated. The single-pdb is not a good solution for release builds
where the .pdb will be shipped.
It's also NOT interchangeable in older versions of the compiler/linker,
and moving to a more modern compiler or linker (unpaired) can prove
very problematic.
Bill
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, October 30, 2007 7:50 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> > 2. in dynamic builds the source pdb and the binary pdb both
> > generating in OutDir using the single file with the name
> > libstdxx.pdb.
>
> This one is more problematic. Source and Binary .pdb's are
> two different file formats, you've corrupted the one creating
> 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
<project>.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.
* <project>.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 <project>.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 <windows.h>, all the
typedefs from these headers are only stored once, rather than in every
.OBJ file.
When you run the linker, it creates <project>.PDB, which holds the
debugging information for the project's .EXE file. All debugging
information, including function prototypes and everything else, is
placed into <project>.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
> $(IntDir)/stdlibxx_src.pdb - which is as temporary as any of
> the object files in the build. But - if you tweak one file
> and recompile, you won't have problems with the resulting
> $(OutDir)/stdlibxx.pdb losing any context from the previous
> .pdb for the modules that aren't rebuilt.
>
> > So you propose to revert the patch only for dynamic builds?
>
> Don't revert, you were on the right track :) I'd just take
> this one step further as I mentioned above.
Farid.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Farid Zaripov wrote:
>
> I don't completely understand which one unstable results could be?
>
> After the patch:
> 1. in static builds the source pdb is generating in OutDir with
> the name libstdxx.pdb; the binary pdb doesn't exist since the
> static library is produced by lib.exe, but not by link.exe.
This is exactly what you want, yes!
> 2. in dynamic builds the source pdb and the binary pdb both
> generating in OutDir using the single file with the name
> libstdxx.pdb.
This one is more problematic. Source and Binary .pdb's are two different
file formats, you've corrupted the one creating the other. You might want
to deploy the source pdb as $(IntDir)/stdlibxx_src.pdb - which is as temporary
as any of the object files in the build. But - if you tweak one file and
recompile, you won't have problems with the resulting $(OutDir)/stdlibxx.pdb
losing any context from the previous .pdb for the modules that aren't rebuilt.
> So you propose to revert the patch only for dynamic builds?
Don't revert, you were on the right track :) I'd just take this one step
further as I mentioned above.
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Monday, October 29, 2007 11:30 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> > faridz@apache.org wrote:
> >> Author: faridz
> >> Date: Thu Oct 25 10:40:21 2007
> >> New Revision: 588290
> >>
> >> URL: http://svn.apache.org/viewvc?rev=588290&view=rev
> >> Log:
> >> 2007-10-25 Farid Zaripov <fa...@epam.com>
> >>
> >> * projectdef.js (projectCreateVCProject): Generate .pdb file
> >> in $(OutDir) instead of $(IntDir). Use common .pdb file
> >> instead of two (compiler's and linker's).
>
> Are you sure you didn't mean to continue inverting these,
> therefore storing the compiler's pdb results in the IntDir?
>
> Yes, the resulting link-output pdb must reside in OutDir as
> you have patched, but combining them may lead to some
> unstable results and also bloated .pdb's without benefits to
> the debugger (?).
I don't completely understand which one unstable results could be?
Before the patch:
1. in static builds the source pdb was generated in IntDir with
the name vc71.pdb for MSVC 7.1 (or vc80.pdb for MSVC 8.0); the
binary pdb doesn't exist since the static library is produced
by lib.exe, but not by link.exe.
2. in dynamic builds the source pdb was generated in IntDir with
the name vc71.pdb for MSVC 7.1 (or vc80.pdb for MSVC 8.0); the
binary pdb was generated in OutDir with the name libstdxx.pdb.
After the patch:
1. in static builds the source pdb is generating in OutDir with
the name libstdxx.pdb; the binary pdb doesn't exist since the
static library is produced by lib.exe, but not by link.exe.
2. in dynamic builds the source pdb and the binary pdb both
generating in OutDir using the single file with the name
libstdxx.pdb.
I suppose you mean that the information from the source pdb in
the dynamic builds will be unuseful for the library users because they
are use the binary .dll file, but not the .obj files. And adding this
information to the binary pdb just increase the pdb file without any
benefits. Right?
So you propose to revert the patch only for dynamic builds?
Farid.
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, October 30, 2007 7:03 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> > The pdb for the static compilation and pdb for the dynamic
> > compilation are different files.
>
> Because the sources are or may be different depending on the
> setting of the _RWSTDDEBUG macro, correct?
I'm just stating the fact that they are the different files because
they
generated in the different directories :) Maybe they are contains the
same data, maybe not (for example due to the differences in the source
files as you mentioned).
> Sounds from what Bill is saying like APR is the same regardless.
> Do the Microsoft libraries come with distinct .pdb files for
> archive and shared libraries?
Yes. The pdb for archive libraries located in Vc7\lib directory (where
.lib files are located) and pdb for the dynamic libraries are located in
%windir%\system32 directory (where the .dll files are located).
Farid.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>> Sent: Monday, October 29, 2007 11:34 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r588290 -
>> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>>
>> William A. Rowe, Jr. wrote:
>>> patched, but combining them may lead to some unstable
>> results and also
>>> bloated .pdb's without benefits to the debugger (?).
>> Footnote - source .pdb's for a static .lib file that you
>> distribute /are/ interesting to the end user, but you
>> shouldn't generate one source pdb anyways for both the static
>> and dynamic compilation of the library.
>
> The pdb for the static compilation and pdb for the dynamic
> compilation are different files.
Because the sources are or may be different depending on
the setting of the _RWSTDDEBUG macro, correct?
Sounds from what Bill is saying like APR is the same regardless.
Do the Microsoft libraries come with distinct .pdb files for
archive and shared libraries?
Martin
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Monday, October 29, 2007 11:34 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> William A. Rowe, Jr. wrote:
> >
> > patched, but combining them may lead to some unstable
> results and also
> > bloated .pdb's without benefits to the debugger (?).
>
> Footnote - source .pdb's for a static .lib file that you
> distribute /are/ interesting to the end user, but you
> shouldn't generate one source pdb anyways for both the static
> and dynamic compilation of the library.
The pdb for the static compilation and pdb for the dynamic
compilation are different files.
Farid.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> patched, but combining them may lead to some unstable results and also
> bloated .pdb's without benefits to the debugger (?).
Footnote - source .pdb's for a static .lib file that you distribute /are/
interesting to the end user, but you shouldn't generate one source pdb
anyways for both the static and dynamic compilation of the library.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> faridz@apache.org wrote:
>> Author: faridz
>> Date: Thu Oct 25 10:40:21 2007
>> New Revision: 588290
>>
>> URL: http://svn.apache.org/viewvc?rev=588290&view=rev
>> Log:
>> 2007-10-25 Farid Zaripov <fa...@epam.com>
>>
>> * projectdef.js (projectCreateVCProject): Generate .pdb file
>> in $(OutDir) instead of $(IntDir). Use common .pdb file
>> instead of two (compiler's and linker's).
Are you sure you didn't mean to continue inverting these, therefore
storing the compiler's pdb results in the IntDir?
Yes, the resulting link-output pdb must reside in OutDir as you have
patched, but combining them may lead to some unstable results and also
bloated .pdb's without benefits to the debugger (?).
Bill
Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, November 06, 2007 2:11 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PING] Re: svn commit: r588290 -
>> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>> I think I understand this part: The .pdb file needs to be in
>> the same directory as the library for the debugger to find it
>> on is own.
>>
>> IIUC, in 4.2.0 we have it in the wrong directory and Farid's
>> patch makes the linker put in the same directory as the lib.
>> Do I have it right, Farid?
>
> Not linker, but librarian (lib.exe). And what do you mean by "wrong
> directory"?
Liviu asked in his post below if it would be possible to "generate
a pdb file in the lib directory" so, presumably, in 4.2.0 the .pdb
file is in some other directory. IIUC, you changed the directory
where the file is placed from what you call $(IntDir) to $(OutDir)
in 588290. So by the "wrong directory" I mean $(IntDir), with
$(OutDir) (presumably) being the right one.
http://www.nabble.com/Use-of--Fd-option-on-Windows-tf4691559.html
>
> The absolute .pdb file path stored in each .obj file (and the .lib
> file in static builds
> is the archive of the .obj files), so .pdb file will be found by linker
> if you don't move it.
What if you install the library in some non-default location or on
a different drive? E.g., what if you install Visual Studio in such
a location? If the object files contain the absolute pathname of
the .pdb files does it mean that the debugger won't be able to find
the debugging symbols for the Visual Studio libraries?
Or can the pathname of the .pdb files be a relative one, perhaps
WRT the library?
> But if you copied the .lib file from the %BUILDDIR%/lib directory to
> another computer
> and build some project, which is uses that library, you need also copy
> the
> corresponding vcx0.pdb file from the %BUILDDIR%/src directory. This is
> for 4.2.0.
So if I build 4.2.0 in, say c:\sebor\stdcxx-4.2.0\lib, i.e., I have
c:\sebor\stdcxx-4.2.0\lib\libstdcxx.4.2.0.lib, where will the .pdb
file be? And if Liviu installs stdcxx 4.2.0 in d:\libs\stdcxx\lib,
i.e., he has d:\libs\stdcxx\lib\libstdcxx.4.2.0.lib, where does he
need to put the .pdb file (and what is its full name)?
>
> In 4.2.x you still need copy the corresponding .pdb file, but in this
> case from the
> directory where the .lib file is located and the name of the .pdb file
> coincide with
> the name of .lib file.
Martin
RE: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, November 06, 2007 2:11 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PING] Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
> I think I understand this part: The .pdb file needs to be in
> the same directory as the library for the debugger to find it
> on is own.
>
> IIUC, in 4.2.0 we have it in the wrong directory and Farid's
> patch makes the linker put in the same directory as the lib.
> Do I have it right, Farid?
Not linker, but librarian (lib.exe). And what do you mean by "wrong
directory"?
The absolute .pdb file path stored in each .obj file (and the .lib
file in static builds
is the archive of the .obj files), so .pdb file will be found by linker
if you don't move it.
But if you copied the .lib file from the %BUILDDIR%/lib directory to
another computer
and build some project, which is uses that library, you need also copy
the
corresponding vcx0.pdb file from the %BUILDDIR%/src directory. This is
for 4.2.0.
In 4.2.x you still need copy the corresponding .pdb file, but in this
case from the
directory where the .lib file is located and the name of the .pdb file
coincide with
the name of .lib file.
> > If they really use a "debug" build, that's a different
> story, you want
> > those to use /O- no-optimization flags so that single
> stepping is not
> > half as confusing ;-)
>
> I'm pretty sure we do that, right Farid?
Yes.
Farid.
Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
William A. Rowe, Jr. wrote:
> Martin Sebor wrote:
>>
>> I meant the problems that Liviu was talking about. I.e., if someone
>> is using a debug build of stdcxx 4.2.0 on Windows, will they be able
>> to step through stdcxx code? If not, I think it would be worthwhile
>> to document why and point them to a patch they can download to make
>> it possible (i.e., your change), or explain how to do it otherwise.
>
> They can step through a debug or release build.
Thanks, I did not know that.
> What is especially nice
> about using the (/Zi) flag to cc and (/debug /opt:ref) flags to link.exe
> is that your .exe looks like a unix stripped binary, no extra debugger
> noise, but that the .pdb contains all the binary -> source/diagnostics
> you would wish from a unix -g build (unstripped).
Right. The GNU strip command makes it possible to create a similar
file that is then readable by gdb but I don't think it's a widely
used feature:
http://sources.redhat.com/gdb/onlinedocs/gdb_16.html#SEC153
http://sourceware.org/binutils/docs-2.17/binutils/strip.html
>
> All that's required is that your favorite win debugger/dr watson can
> see the .pdb alongside the binary (or you put in some horribly complex
> pathing or resolve to a symbol server), and that somewhere you have
> the sources where the debugger can load them up. It will prompt the
> user for "where is foo.c?"
I think I understand this part: The .pdb file needs to be in the
same directory as the library for the debugger to find it on is
own.
IIUC, in 4.2.0 we have it in the wrong directory and Farid's patch
makes the linker put in the same directory as the lib. Do I have
it right, Farid?
>
> In httpd, I'd simply set up a subdirectory of binaries (and I've now
> moved all of this to http://archive.apache.org/dist/httpd/binaries/win32/
> in the symbols/ subdirectory - so it never hits www. mirror server) and
> the rare soul who wants the symbols just unzip's them right on top of
> an installed program.
Super nifty! A repository of prebuilt binaries for all supported
platforms.
We might want to think about something like this (only for the
most common configuration of the library, i.e., optimized, thread
safe, shared lib).
>
> If they really use a "debug" build, that's a different story, you want
> those to use /O- no-optimization flags so that single stepping is not
> half as confusing ;-)
I'm pretty sure we do that, right Farid?
Martin
Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Martin Sebor wrote:
>
> I meant the problems that Liviu was talking about. I.e., if someone
> is using a debug build of stdcxx 4.2.0 on Windows, will they be able
> to step through stdcxx code? If not, I think it would be worthwhile
> to document why and point them to a patch they can download to make
> it possible (i.e., your change), or explain how to do it otherwise.
They can step through a debug or release build. What is especially nice
about using the (/Zi) flag to cc and (/debug /opt:ref) flags to link.exe
is that your .exe looks like a unix stripped binary, no extra debugger
noise, but that the .pdb contains all the binary -> source/diagnostics
you would wish from a unix -g build (unstripped).
All that's required is that your favorite win debugger/dr watson can
see the .pdb alongside the binary (or you put in some horribly complex
pathing or resolve to a symbol server), and that somewhere you have
the sources where the debugger can load them up. It will prompt the
user for "where is foo.c?"
In httpd, I'd simply set up a subdirectory of binaries (and I've now
moved all of this to http://archive.apache.org/dist/httpd/binaries/win32/
in the symbols/ subdirectory - so it never hits www. mirror server) and
the rare soul who wants the symbols just unzip's them right on top of
an installed program.
If they really use a "debug" build, that's a different story, you want
those to use /O- no-optimization flags so that single stepping is not
half as confusing ;-)
Bill
Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, November 05, 2007 6:55 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: [PING] Re: svn commit: r588290 -
>> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>>
>> Martin Sebor wrote:
>>> If this fixes the .pdb issue that Liviu wrote about last
>> week it would
>>> be good to have a record of the problems our users can
>> expect to run
>>> into as a result (assuming the problem is real).
>> Farid, is this something we should document (in the form of an issue)?
>
> As I said here
> (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg05872.ht
> ml)
> the only what has changed is the location and the name of the pdb file
> for
> the static builds. I'm not sure of any problems of our users, which
> would be
> caused by this change.
I meant the problems that Liviu was talking about. I.e., if someone
is using a debug build of stdcxx 4.2.0 on Windows, will they be able
to step through stdcxx code? If not, I think it would be worthwhile
to document why and point them to a patch they can download to make
it possible (i.e., your change), or explain how to do it otherwise.
Martin
RE: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, November 05, 2007 6:55 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: [PING] Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> Martin Sebor wrote:
> > If this fixes the .pdb issue that Liviu wrote about last
> week it would
> > be good to have a record of the problems our users can
> expect to run
> > into as a result (assuming the problem is real).
>
> Farid, is this something we should document (in the form of an issue)?
As I said here
(http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg05872.ht
ml)
the only what has changed is the location and the name of the pdb file
for
the static builds. I'm not sure of any problems of our users, which
would be
caused by this change.
Farid.
[PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
> If this fixes the .pdb issue that Liviu wrote about last week it
> would be good to have a record of the problems our users can expect
> to run into as a result (assuming the problem is real).
Farid, is this something we should document (in the form of an issue)?
Martin
>
> Martin
>
> faridz@apache.org wrote:
>> Author: faridz
>> Date: Thu Oct 25 10:40:21 2007
>> New Revision: 588290
>>
>> URL: http://svn.apache.org/viewvc?rev=588290&view=rev
>> Log:
>> 2007-10-25 Farid Zaripov <fa...@epam.com>
>>
>> * projectdef.js (projectCreateVCProject): Generate .pdb file
>> in $(OutDir) instead of $(IntDir). Use common .pdb file
>> instead of two (compiler's and linker's).
>>
>> Modified:
>> incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>>
>> Modified:
>> incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>> URL:
>> http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js?rev=588290&r1=588289&r2=588290&view=diff
>>
>> ==============================================================================
>>
>> --- incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>> (original)
>> +++ incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>> Thu Oct 25 10:40:21 2007
>> @@ -411,6 +411,23 @@
>>
>> var allMacros = prjMacros.concat(cfgMacros);
>>
>> + var OutFile = this.OutFile != null ?
>> + ReplaceMacros(this.OutFile, allMacros) :
>> + "$(OutDir)\\" + PrjName + ext;
>> +
>> + var IngoreLibs = "";
>> + if (confInfo.dll)
>> + {
>> + IngoreLibs = confInfo.debug ? "msvcprtd.lib" :
>> "msvcprt.lib";
>> + }
>> + else
>> + {
>> + if (confInfo.mt || NOSTCRT)
>> + IngoreLibs = confInfo.debug ? "libcpmtd.lib" :
>> "libcpmt.lib";
>> + else
>> + IngoreLibs = confInfo.debug ? "libcpd.lib" :
>> "libcp.lib";
>> + }
>> +
>> var compiler = conf.Tools.Item("VCCLCompilerTool");
>> if (null != compiler)
>> {
>> @@ -423,6 +440,7 @@
>> if (null != this.PrepOpts)
>> compiler.GeneratePreprocessedFile = this.PrepOpts;
>> compiler.DebugInformationFormat = debugEnabled;
>> + compiler.ProgramDataBaseFileName = changeFileExt(OutFile,
>> "pdb");
>> compiler.SuppressStartupBanner = true;
>> compiler.WarningLevel = warningLevel_3;
>> setProperty(compiler.Detect64BitPortabilityProblems, false);
>> @@ -486,28 +504,17 @@
>> linker.AdditionalOptions = LDFLAGS + " " +
>> (null != this.LnkOpts ? this.LnkOpts : "");
>>
>> - linker.LinkIncremental = linkIncrementalNo;
>> - linker.SuppressStartupBanner = true;
>> - linker.GenerateDebugInformation = true;
>> if (null != this.Libs)
>> linker.AdditionalDependencies = this.Libs;
>>
>> - if (confInfo.dll)
>> - {
>> - linker.IgnoreDefaultLibraryNames =
>> - confInfo.debug ? "msvcprtd.lib" : "msvcprt.lib";
>> - }
>> - else
>> - {
>> - if (confInfo.mt || NOSTCRT)
>> - linker.IgnoreDefaultLibraryNames =
>> - confInfo.debug ? "libcpmtd.lib" : "libcpmt.lib";
>> - else
>> - linker.IgnoreDefaultLibraryNames =
>> - confInfo.debug ? "libcpd.lib" : "libcp.lib";
>> - }
>> -
>> + linker.LinkIncremental = linkIncrementalNo;
>> + linker.SuppressStartupBanner = true;
>> + linker.GenerateDebugInformation = true;
>> + // use the compiler's .pdb
>> + linker.ProgramDatabaseFile = "";
>> + linker.IgnoreDefaultLibraryNames = IngoreLibs;
>> linker.SubSystem = this.SubSystem;
>> +
>> if (confInfo.debug)
>> {
>> linker.OptimizeReferences = optReferencesDefault;
>> @@ -519,12 +526,7 @@
>> linker.EnableCOMDATFolding = optFolding;
>> }
>>
>> - if (this.OutFile != null)
>> - linker.OutputFile = ReplaceMacros(this.OutFile,
>> allMacros);
>> - else
>> - linker.OutputFile = "$(OutDir)\\" + PrjName + ext;
>> -
>> - linker.ProgramDatabaseFile =
>> changeFileExt(linker.OutputFile, "pdb");
>> + linker.OutputFile = OutFile;
>>
>> if (this.Type != typeApplication)
>> linker.ImportLibrary =
>> changeFileExt(linker.OutputFile, "lib");
>> @@ -537,10 +539,8 @@
>> linker.AdditionalOptions = this.LibOpts;
>> librarian.SuppressStartupBanner = true;
>> - if (this.OutFile != null)
>> - librarian.OutputFile = ReplaceMacros(this.OutFile,
>> allMacros);
>> - else
>> - librarian.OutputFile = "$(OutDir)\\" + PrjName + ".lib";
>> + librarian.IgnoreDefaultLibraryNames = IngoreLibs;
>> + librarian.OutputFile = OutFile;
>> }
>>
>> if (null != this.PreLinkCmd)
>>
>>
>
>
RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, October 29, 2007 10:54 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 -
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> If this fixes the .pdb issue that Liviu wrote about last week
> it would be good to have a record of the problems our users
> can expect to run into as a result (assuming the problem is real).
Since the latest change, the only what was changed is location and
name of the (source) pdb for the static builds. Instead
$(IntDir)\vcxx.pdb now it will be $(OutDir)\libstdxx.pdb.
Farid.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Posted by Martin Sebor <se...@roguewave.com>.
If this fixes the .pdb issue that Liviu wrote about last week it
would be good to have a record of the problems our users can expect
to run into as a result (assuming the problem is real).
Martin
faridz@apache.org wrote:
> Author: faridz
> Date: Thu Oct 25 10:40:21 2007
> New Revision: 588290
>
> URL: http://svn.apache.org/viewvc?rev=588290&view=rev
> Log:
> 2007-10-25 Farid Zaripov <fa...@epam.com>
>
> * projectdef.js (projectCreateVCProject): Generate .pdb file
> in $(OutDir) instead of $(IntDir). Use common .pdb file
> instead of two (compiler's and linker's).
>
> Modified:
> incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
>
> Modified: incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js?rev=588290&r1=588289&r2=588290&view=diff
> ==============================================================================
> --- incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js (original)
> +++ incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js Thu Oct 25 10:40:21 2007
> @@ -411,6 +411,23 @@
>
> var allMacros = prjMacros.concat(cfgMacros);
>
> + var OutFile = this.OutFile != null ?
> + ReplaceMacros(this.OutFile, allMacros) :
> + "$(OutDir)\\" + PrjName + ext;
> +
> + var IngoreLibs = "";
> + if (confInfo.dll)
> + {
> + IngoreLibs = confInfo.debug ? "msvcprtd.lib" : "msvcprt.lib";
> + }
> + else
> + {
> + if (confInfo.mt || NOSTCRT)
> + IngoreLibs = confInfo.debug ? "libcpmtd.lib" : "libcpmt.lib";
> + else
> + IngoreLibs = confInfo.debug ? "libcpd.lib" : "libcp.lib";
> + }
> +
> var compiler = conf.Tools.Item("VCCLCompilerTool");
> if (null != compiler)
> {
> @@ -423,6 +440,7 @@
> if (null != this.PrepOpts)
> compiler.GeneratePreprocessedFile = this.PrepOpts;
> compiler.DebugInformationFormat = debugEnabled;
> + compiler.ProgramDataBaseFileName = changeFileExt(OutFile, "pdb");
> compiler.SuppressStartupBanner = true;
> compiler.WarningLevel = warningLevel_3;
> setProperty(compiler.Detect64BitPortabilityProblems, false);
> @@ -486,28 +504,17 @@
> linker.AdditionalOptions = LDFLAGS + " " +
> (null != this.LnkOpts ? this.LnkOpts : "");
>
> - linker.LinkIncremental = linkIncrementalNo;
> - linker.SuppressStartupBanner = true;
> - linker.GenerateDebugInformation = true;
> if (null != this.Libs)
> linker.AdditionalDependencies = this.Libs;
>
> - if (confInfo.dll)
> - {
> - linker.IgnoreDefaultLibraryNames =
> - confInfo.debug ? "msvcprtd.lib" : "msvcprt.lib";
> - }
> - else
> - {
> - if (confInfo.mt || NOSTCRT)
> - linker.IgnoreDefaultLibraryNames =
> - confInfo.debug ? "libcpmtd.lib" : "libcpmt.lib";
> - else
> - linker.IgnoreDefaultLibraryNames =
> - confInfo.debug ? "libcpd.lib" : "libcp.lib";
> - }
> -
> + linker.LinkIncremental = linkIncrementalNo;
> + linker.SuppressStartupBanner = true;
> + linker.GenerateDebugInformation = true;
> + // use the compiler's .pdb
> + linker.ProgramDatabaseFile = "";
> + linker.IgnoreDefaultLibraryNames = IngoreLibs;
> linker.SubSystem = this.SubSystem;
> +
> if (confInfo.debug)
> {
> linker.OptimizeReferences = optReferencesDefault;
> @@ -519,12 +526,7 @@
> linker.EnableCOMDATFolding = optFolding;
> }
>
> - if (this.OutFile != null)
> - linker.OutputFile = ReplaceMacros(this.OutFile, allMacros);
> - else
> - linker.OutputFile = "$(OutDir)\\" + PrjName + ext;
> -
> - linker.ProgramDatabaseFile = changeFileExt(linker.OutputFile, "pdb");
> + linker.OutputFile = OutFile;
>
> if (this.Type != typeApplication)
> linker.ImportLibrary = changeFileExt(linker.OutputFile, "lib");
> @@ -537,10 +539,8 @@
> linker.AdditionalOptions = this.LibOpts;
>
> librarian.SuppressStartupBanner = true;
> - if (this.OutFile != null)
> - librarian.OutputFile = ReplaceMacros(this.OutFile, allMacros);
> - else
> - librarian.OutputFile = "$(OutDir)\\" + PrjName + ".lib";
> + librarian.IgnoreDefaultLibraryNames = IngoreLibs;
> + librarian.OutputFile = OutFile;
> }
>
> if (null != this.PreLinkCmd)
>
>