MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013074CMakeCMakepublic2012-03-29 12:542016-06-10 14:31
ReporterCesar 
Assigned ToKitware Robot 
PriorityhighSeveritymajorReproducibilityrandom
StatusclosedResolutionmoved 
PlatformPCOSWindowsOS VersionServer 2003
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0013074: Parallel builds fail consistently when embedding manifest
DescriptionThis happens due to a race condition in Microsoft Visual Studio 2008 when building things in parallel. Here's one example:

115>mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file ".\Release\myprogram.exe". Access is denied.

Of course, this happens more often when we're really trying to get a build for a customer, or when it is the nightly build that triggers regression tests.

I know we can disable manifest generation with /MANIFEST:NO, but that's not an option - our software does need the manifests or we get the dreaded "side-by-side error"s. There doesn't seem to be a "proper solution" either. Here's a suggestion: allow me to specify an arbitrary pause, in seconds, between the linking and the mt.exe calls (I don't know if that is possible). A more involved solution would be to execute mt.exe as a post-build step, but for that I need CMake to pass /MANIFEST to the linker while not calling mt.exe after that automatically. Any other suggestions welcome.

This, by the way, did not happen when using our old Makefile-based system, which called mt.exe right after the linker with no pauses. Then again, that was being executed from Cygwin and it was much slower.
Steps To ReproduceBuild a large project in parallel. For my project, it fails 1 out of 3 or 4 times.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-03-29 12:54CesarNew Issue
2012-03-29 13:12Bill HoffmanNote Added: 0029000
2012-03-29 13:42CesarNote Added: 0029001
2012-03-29 13:48CesarNote Added: 0029002
2012-03-29 13:49CesarNote Edited: 0029002bug_revision_view_page.php?bugnote_id=29002#r583
2012-08-11 21:35David ColeStatusnew => backlog
2012-08-11 21:35David ColeNote Added: 0030385
2016-06-10 14:28Kitware RobotNote Added: 0042013
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029000)
Bill Hoffman   
2012-03-29 13:12   
What generator are you using? I have never seen this and build lots of software and have tons of nightly dashboards. It might be anti-virus causing your grief?
(0029001)
Cesar   
2012-03-29 13:42   
Nope. I found the "anti-virus solution" online too, we don't have any running. I'm looking at CMake's source code and may have something else to report shortly on the linking problem.
(0029002)
Cesar   
2012-03-29 13:48   
(edited on: 2012-03-29 13:49)
Here's one potential problem: CMake seems to be thinking that we want to do incremental linking even when we explicitly disable it. Here's how I found this out:

* When we generate the project, all the linker flags have /INCREMENTAL:NO specified, and no other /INCREMENTAL flags (verified by looking at CMakeCache.txt).
* Now, when I open Visual Studio and look at the linker command line call (for the release variant), I see there is a /MANIFESTFILE option being passed, with an "intermediate" named manifest.
* Back to CMake's source code, it seems that /MANIFESTFILE is only specified when the VisualStudioLinkIncremental is called, which happens only when CMake thinks we want to do incremental linking.

Something is not working here.
(0030385)
David Cole   
2012-08-11 21:35   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

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 who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0042013)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.