View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014062CMakeCMakepublic2013-04-04 17:362014-02-18 09:58
ReporterRobert McMillan 
Assigned ToBrad King 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindowsOSWindowsOS VersionAll
Product VersionCMake 2.8.10 
Target VersionCMake 2.8.12Fixed in VersionCMake 2.8.12 
Summary0014062: Setting Compiler and Linker PDB to the same path in Visual Studio is unsupported.
DescriptionI just got conformation from Calvin Clark, a Senior Consultant with Microsoft, that CMake's practice of setting the Compiler and Linker PDB to the same file is unsupported. It can caused corruption of the PDB during incremental linking, and it can cause very severe linker/build performance degradation for large projects. We have been experiencing a 4X increase in link times due to this issue, and when you multiply that by 100 projects in our app, times 100 developers on our project, it adds up to a very significant loss of productivity. We are considering making a local build of CMake to fix the issue, it is very serious.

The feature in 2.8.10 to override the PDB location is not sufficient, because this will change the location for both the compiler and linker PDB.

Also, users who are experiencing the issue have no idea why their build times are slow, and that the PDB location is the cause of the problem.

The correct fix would really be to NOT SET THE COMPILER PDB LOCATION AT ALL!

This will result in a vc100.pdb file being created automatically in the intermediate directory, as Microsoft intended. The compiler PDB is truly an intermediate file, and is not supposed to be a permanent artifact of the build, unlike the linker PDB. They are fundamentally different animals.

I can put you in touch with Microsoft if you want direct confirmation of my findings.
Steps To ReproduceGenerate any Visual Studio project using Cmake.

The Compiler and Linker PDB location is the same, this is unsupported and causes problems.
TagsNo tags attached.
Attached Files

 Relationships
related to 0011899closedBrad King Put compiler's program database files into intermediate directory rather than output one for VS 2005 
related to 0010830closedBrad King Add option to specify output of Visual Studio .pdb files (Debug symbols) 
has duplicate 0014158closed CMake generated project doesn't create PDB files in the right place. 
related to 0014577closedBrad King Need to map /Fd to ProgramDataBaseFileName in VS 7,8,9 
related to 0014600closedBrad King Document PDB behavior w.r.t. static libraries 
related to 0014763closedBrad King Add target properties to specify MS compiler PDB files 

  Notes
(0032760)
Brad King (manager)
2013-04-05 08:06

It looks like the compiler pdb setting (ProgramDataBaseFileName) was first added way back when the VS 7 generator was first written:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f5e672fe [^]

Later the /Fd option was added to the CMAKE_<LANG>_COMPILE_OBJECT build rules for MSVC so that Makefile builds would use it too:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6ef33f5 [^]

There is related discussion in issue 0011899 and I suspect both can be solved with the same fix.
(0032761)
Brad King (manager)
2013-04-05 08:09

There is confusion about the need for the /Fd option when compiling for STATIC libraries. While the linker may generate the .pdb file for a SHARED library (.dll), what does the librarian do for STATIC libraries (.lib)? Why is the /Fd option available if it should never be used?
(0032762)
Robert McMillan (reporter)
2013-04-05 09:02
edited on: 2013-04-05 09:04

The Microsoft Wizard output should probably be a guideline. Static lib output is similar to shared lib output - i.e. /Fd is set to $(IntDir)vc$(PlatformToolsetVersion).pdb, /PDB is set to $(TargetDir)$(TargetName).pdb. Maybe my statement about 'not setting this option' was too strong, at a minimum the compiler .pdb should always be placed in the IntDir. If you do clear the /Fd setting completely, you will still get a vc100.pdb, but it will be placed in the project directory, so it's probably preferable to set the option but use the intermediate directory. To avoid confusion with the Target PDB, it's probably a good idea to follow Microsoft's naming convention, or use a different name than the Target PDB.

(0032766)
Brad King (manager)
2013-04-05 11:59

Okay, please try out this patch:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ba1b08 [^]
(0032767)
Robert McMillan (reporter)
2013-04-05 13:16

Ok, we have never built CMake before, we have a group at one of our sites that was going to try to figure it out and make their own fix for this issue, I need to check with them and see if they can try building this patch.

Thank you very much for the quick turnaround though, we really appreciate it!
(0032768)
Brad King (manager)
2013-04-05 13:25

Re 0014062:0032767: The fix should be available in the next nightly build to appear here:

 http://www.cmake.org/files/dev/?C=M;O=D [^]
(0032793)
Robert McMillan (reporter)
2013-04-09 17:34

We pulled down the latest build and verified that this change results in the desired behavior, at least for Visual Studio 2010. The behavior is now the same as you get with the Visual Studio wizards, which is great. I really appreciate you taking the time to work on this issue, we will probably move to this version as we need to start thinking about moving to VS2012 anyway. If we do run into any issues with the new version, I will let you know. Thanks again!
(0032818)
Brad King (manager)
2013-04-12 11:53

Okay, I've gotten this and related fixes through our nightly testing cleanly. Here are the commits:

 VS: Separate compiler and linker PDB files (0011899, 0014062)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ba1b08 [^]

 MSVC: Invoke 'link' directly for executables
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb9f73de [^]

 Ninja: Fix OBJECT_DIR placeholder path conversion
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87c0d16a [^]
(0034057)
Robert Maynard (manager)
2013-10-07 10:09

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2013-04-04 17:36 Robert McMillan New Issue
2013-04-05 07:58 Brad King Relationship added related to 0011899
2013-04-05 07:58 Brad King Relationship added related to 0010830
2013-04-05 08:06 Brad King Note Added: 0032760
2013-04-05 08:09 Brad King Note Added: 0032761
2013-04-05 09:02 Robert McMillan Note Added: 0032762
2013-04-05 09:04 Robert McMillan Note Edited: 0032762
2013-04-05 11:59 Brad King Note Added: 0032766
2013-04-05 11:59 Brad King Assigned To => Brad King
2013-04-05 11:59 Brad King Status new => assigned
2013-04-05 13:16 Robert McMillan Note Added: 0032767
2013-04-05 13:25 Brad King Note Added: 0032768
2013-04-09 17:34 Robert McMillan Note Added: 0032793
2013-04-12 11:53 Brad King Note Added: 0032818
2013-04-12 11:53 Brad King Status assigned => resolved
2013-04-12 11:53 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-05-23 08:33 Brad King Relationship added has duplicate 0014158
2013-10-07 10:09 Robert Maynard Note Added: 0034057
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:58 Brad King Relationship added related to 0014763


Copyright © 2000 - 2018 MantisBT Team