You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/11/05 17:54:32 UTC
[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)?
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: [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.