View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011899 | CMake | CMake | public | 2011-02-26 03:53 | 2014-02-18 09:59 | ||||
Reporter | Yuri | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | tweak | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Visual Studio 2005 | OS | Windows | OS Version | |||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | CMake 2.8.12 | Fixed in Version | CMake 2.8.12 | ||||||
Summary | 0011899: Put compiler's program database files into intermediate directory rather than output one for VS 2005 | ||||||||
Description | Now in cmLocalVisualStudio7Generator.cxx the path for *compiler's* program database files is hard-coded: // We need to specify a program database file name even for // non-debug configurations because VS still creates .idb files. fout << "\t\t\t\tProgramDataBaseFileName=\"" << this->ConvertToXMLOutputPathSingle( target.GetDirectory(configName).c_str()) << "/" << target.GetPDBName(configName) << "\"\n"; However, these files are temporary and used only by linker to produce the final .pdb file. Moreover, these files aren't usable by debugger (AFAIK). So the main complaint is when I put all output into single directory, it becomes clogged with idb files. The things much worse when using tools like IncrediBuild - it generates one idb file per source (or per job), therefore the number of files there grows too rapidly. Why not Just put $(IntDir) there, like it is done for object files? I suppose this can solve other issues, like 0010370. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |||||||||||||||||||||||||||||||||||||||||||||||||||
|
Relationships |
Notes | |
(0025594) Brad King (manager) 2011-02-28 09:13 edited on: 2011-02-28 09:57 |
History of interest: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=712345ff [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33ee8371 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=770ffb16 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8952f498 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68ed752b [^] |
(0025595) Brad King (manager) 2011-02-28 09:28 edited on: 2011-02-28 09:41 |
Documentation of interest: http://msdn.microsoft.com/en-us/library/9wst99a9%28v=vs.80%29.aspx [^] (cl /Fd Program Database File Name) http://msdn.microsoft.com/en-us/library/kwx19e36%28v=VS.80%29.aspx [^] (link /PDB Use Program Database) http://msdn.microsoft.com/en-us/library/958x11bc%28v=vs.80%29.aspx [^] (cl /Z Debug Information Format) http://msdn.microsoft.com/en-us/library/1d5fbft1%28v=VS.80%29.aspx [^] (link: .pdb Files as Linker Input) http://msdn.microsoft.com/en-us/library/h34w59b3%28v=VS.80%29.aspx [^] (lib.exe) |
(0025596) Brad King (manager) 2011-02-28 09:49 |
I think the current code may be based on a misunderstanding of the relationship between the compiler's and linker's .pdb files. I'm not sure though because it was written a long time ago and the refactored and moved about. Okay, so "cl /Fd..." puts the debug information into a temporary .pdb file that is referenced by each .obj file written. Then "link /pdb:..." copies the information referenced by each .obj file into a final .pdb file corresponding to the .dll or .exe produced. This works well for shared libraries and executables. However, for static libraries consider this note from the "cl /Z" documentation linked in 0011899:0025595: If you create a library from objects that were compiled using this option, the associated .pdb file must be available when the library is linked to a program. Thus, if you distribute the library, you must distribute the PDB. This says that if a static .lib were to be distributed then all the debug symbols should be in a single matching .pdb file. Since the librarian does not copy/consolidate debug symbols this means all the /Fd options used when compiling objects in the static library must reference the same .pdb file. |
(0025597) Brad King (manager) 2011-02-28 10:02 |
It looks like the current behavior was a result of development specifically for the static library case. See issue 0000091: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62bd5b7c [^] |
(0025598) Yuri (reporter) 2011-02-28 10:05 |
That's exactly what I was trying to say in this bug: compiler's PDBs are different from linker's PDBs. But this is good point: for static libraries compiler's pdb files are useful, however, for dynamic ones (including executables), they are successfully found at linking time and only resulting linker's pdb matters. That's why allowing to specify directory for .pdb files is generally good idea. But in real world, if you want to redistribute your static libraries it's better to use C7-compatible debug info. If you don't redistribute static libraries (for example, use it locally to build different application form the same source) - you don't need compiler's pdb either. |
(0025600) Brad King (manager) 2011-02-28 10:12 |
Any work on this issue should account for issue 0010830 too because the changes will otherwise conflict. |
(0025601) Yuri (reporter) 2011-02-28 10:17 |
I also encountered problems with these compiler's PDB output - when you build in parallel several files (accidentally or not) and they write to the same PDB file, this file becomes corrupted or contains only part of information. It was during my experiments to make single PCH file for multiple similar projects (with pure VS projects). PCH is also bound to some PDB file. |
(0030519) Brad King (manager) 2012-08-13 10:37 |
Sending issues I'm not actively working on to the backlog to await someone with time for them. If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on. |
(0030962) Yuchen Deng (reporter) 2012-09-09 00:24 |
So sad! It should been fixed soon. |
(0033101) Brad King (manager) 2013-05-20 08:50 |
This issue has been addressed along with 0014062 as described in 0014062:0032818. |
(0034052) Robert Maynard (manager) 2013-10-07 10:09 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2011-02-26 03:53 | Yuri | New Issue | |
2011-02-28 09:02 | Brad King | Relationship added | duplicate of 0010830 |
2011-02-28 09:02 | Brad King | Relationship deleted | 0010830 |
2011-02-28 09:03 | Brad King | Assigned To | => Brad King |
2011-02-28 09:03 | Brad King | Status | new => assigned |
2011-02-28 09:03 | Brad King | Relationship added | related to 0010370 |
2011-02-28 09:11 | Brad King | Assigned To | Brad King => |
2011-02-28 09:11 | Brad King | Assigned To | => Brad King |
2011-02-28 09:11 | Brad King | Relationship added | related to 0009042 |
2011-02-28 09:13 | Brad King | Note Added: 0025594 | |
2011-02-28 09:28 | Brad King | Note Added: 0025595 | |
2011-02-28 09:32 | Brad King | Relationship added | related to 0010830 |
2011-02-28 09:33 | Brad King | Note Edited: 0025595 | |
2011-02-28 09:41 | Brad King | Note Edited: 0025595 | |
2011-02-28 09:49 | Brad King | Note Added: 0025596 | |
2011-02-28 09:57 | Brad King | Note Edited: 0025594 | |
2011-02-28 09:58 | Brad King | Relationship added | related to 0003277 |
2011-02-28 09:58 | Brad King | Relationship added | related to 0003738 |
2011-02-28 10:01 | Brad King | Relationship added | related to 0000091 |
2011-02-28 10:02 | Brad King | Note Added: 0025597 | |
2011-02-28 10:05 | Yuri | Note Added: 0025598 | |
2011-02-28 10:12 | Brad King | Note Added: 0025600 | |
2011-02-28 10:17 | Yuri | Note Added: 0025601 | |
2012-08-13 10:37 | Brad King | Status | assigned => backlog |
2012-08-13 10:37 | Brad King | Note Added: 0030519 | |
2012-09-09 00:24 | Yuchen Deng | Note Added: 0030962 | |
2013-04-05 07:58 | Brad King | Relationship added | related to 0014062 |
2013-05-20 08:50 | Brad King | Note Added: 0033101 | |
2013-05-20 08:51 | Brad King | Status | backlog => resolved |
2013-05-20 08:51 | Brad King | Resolution | open => fixed |
2013-05-20 08:51 | Brad King | Fixed in Version | => CMake 2.8.12 |
2013-05-20 08:51 | Brad King | Target Version | => CMake 2.8.12 |
2013-10-07 10:09 | Robert Maynard | Note Added: 0034052 | |
2013-10-07 10:09 | Robert Maynard | Status | resolved => closed |
2013-11-18 08:35 | Brad King | Relationship added | related to 0014577 |
2013-11-27 10:29 | Brad King | Relationship added | related to 0014600 |
2014-02-18 09:59 | Brad King | Relationship added | related to 0014763 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |