|
Notes |
|
|
(0028563)
|
|
Andras Lasso
|
|
2012-02-12 10:18
|
|
Example during Slicer4 build:
8>1>c:\users\lasso\devel\slicer4-bin\cmcurl\urldata.h(585) : error C2061: syntax error : identifier 'ssize_t'
Caused by these failed tests:
8>-- Check size of long
8>-- Check size of long - failed
8>-- Check size of __int64
8>-- Check size of __int64 - failed
Normally (90% of the cases) you get:
8>-- Check size of long
8>-- Check size of long - done
8>-- Check size of __int64
8>-- Check size of __int64 - done |
|
|
|
(0028567)
|
|
Bill Hoffman
|
|
2012-02-13 08:39
|
|
|
This is a really hard problem. I just ran the curl test 10 times on my windows 7 box with no failure. I am not sure what does it but SOME win 7 machines seem to have this issue, and some do not. This sort of thing started showing up with vista and never totally went away. For some reason some machines are much worst than others. |
|
|
|
(0028570)
|
|
Brad King
|
|
2012-02-13 09:06
|
|
I do lots of development on Win7 64-bit (with an AV tool) and have never seen this problem. I have VS 6, 7.1, 8, 9, 10 installed and they all work. Sometimes I run the entire CMake test suite in parallel on 3 of the IDEs at once.
I run as a "Standard" user account that is not in the power users or administrators group. Under what kind of account are you running Andras? |
|
|
|
(0028572)
|
|
Brad King
|
|
2012-02-13 10:09
|
|
Please build CMake from source after applying attached patch
16b1a6e4+0001-try_compile-Use-random-executable-file-name-12957.patch
It teaches try_compile to use a different file name every time to avoid conflict when the filesystem hangs on to an old file for any reason. |
|
|
|
(0028582)
|
|
Andras Lasso
|
|
2012-02-14 00:42
|
|
Thanks for all the replies.
I am a local admin on my computers.
To reproduce the problem you can try deleting cmakecache & running cmake continuously while doing CPU and I/O intensive work.
I'll apply the patch and let you know if it helped. |
|
|
|
(0028597)
|
|
Andras Lasso
|
2012-02-15 16:28
(edited on: 2012-02-15 17:08) |
|
Unfortunately, after applying the 16b1a6e4+0001-try_compile-Use-random-executable-file-name-12957.patch to CMake-2.8.7 the problem is still reproducible:
14>47>c:\users\lasso\devel\slicer4-cm287p-bin\vtk\common\vtkDataArrayTemplate.txx(837) : error C2491: 'vtkDataArrayTemplate<T>::SetComponent' : definition of dllimport function not allowed
Caused by these failed tests:
-- Checking support for full template specialization syntax
-- Checking support for full template specialization syntax -- yes
-- Checking support for C++ explicit template instantiation
-- Checking support for C++ explicit template instantiation -- no
Normally you get:
-- Checking support for full template specialization syntax
-- Checking support for full template specialization syntax -- yes
-- Checking support for C++ explicit template instantiation
-- Checking support for C++ explicit template instantiation -- yes
CMakeError.log:
-----
Determining if the C++ compiler supports explict template instantiation failed with the following output:
Change Dir: C:/Users/lasso/devel/Slicer4-cm287p2-bin/VTK-build/CMakeTmp/TestExplicitInstantiation/Build
Run Build Command:c:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com EXPLICIT.sln /build Debug /project cmTryCompileExec
Microsoft (R) Visual Studio Version 9.0.21022.8.
Copyright (C) Microsoft Corp. All rights reserved.
Invalid project
-----
=> so, it seems that the patch does not change the project name for this special case (EXPLICIT.sln), as normally you get something like this (not the project name: "cmTryCompileExec3309943481"):
Determining if the SO_REUSEADDR exist failed with the following output:
Change Dir: C:/Users/lasso/devel/Slicer4-cm287p2-bin/VTK-build/CMakeFiles/CMakeTmp
Run Build Command:c:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec3309943481
|
|
|
|
(0028598)
|
|
Andras Lasso
|
|
2012-02-15 16:38
|
|
Today I've got a somewhat different pattern as well (during Slicer4 build):
19>------ Build started: Project: CTK, Configuration: Release Win32 ------
...
19>-- Looking for Q_WS_MAC - not found.
19>-- Found Qt4: C:/Qt/4.7.3/bin/qmake.exe (found version "4.7.3")
19>CMake Error at CMakeLists.txt:631 (message):
19> Failed to compile DGraph application.
19> Change Dir:
19> C:/Users/lasso/devel/Slicer4-cm287p-bin/CTK-build/Utilities/DGraph
19>
19> Run Build Command:c:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com DGraph.sln
19> /build Debug /project cmTryCompileExec
19>
19> Microsoft (R) Visual Studio Version 9.0.21022.8.
19> Copyright (C) Microsoft Corp. All rights reserved.
19>
19> Invalid project
19>
19> Use:
19> devenv [solutionfile | projectfile | anyfile.ext] [switches]
19>
19> The first argument for devenv is usually a solution file or project file.
19> You can also use any other file as the first argument if you want to have
...
19> instead of IDE paths for VC++ builds.
19>
19> To attach the debugger from the command line, use:
19> VsJITDebugger.exe -p <pid>
19>-- Configuring incomplete, errors occurred!
19>Project : error PRJ0019: A tool returned an error code from "Performing configure step for 'CTK'"
19>Build log was saved at "file://c:\Users\lasso\devel\Slicer4-cm287p-bin\CTK.dir\Release\BuildLog.htm" [^]
19>CTK - 1 error(s), 0 warning(s)
The directory (C:/Users/lasso/devel/Slicer4-cm287p-bin/CTK-build/Utilities/DGraph) and the solution file (c:\Users\lasso\devel\Slicer4-cm287p-bin\CTK-build\Utilities\DGraph\DGraph.sln) does exist on the computer and the sln file can be built without errors. However, due to some reason somehow the build from CMake failed. |
|
|
|
(0028599)
|
|
Brad King
|
|
2012-02-15 16:50
|
|
Re 0012957:0028597: If the patch did not solve the problem then I do not think this is due to rapid creation and deletion of the same executable.
Please try creating a "Standard" user account your Win7 machine for testing purposes. Can you reproduce it under said account? |
|
|
|
(0028600)
|
|
Andras Lasso
|
|
2012-02-15 17:38
|
|
In both error cases the failed project was called "cmTryCompileExec" without the postfixes that the patch supposed to add. So maybe the patch could help, but there are some special cases when still not modifies the cmTryCompileExec name or having a different name than cmTryCompileExec might cause some problems.
I'll do some more testing of the patch and then try to reproduce the problem with "Standard" user account. |
|
|
|
(0028601)
|
|
Andras Lasso
|
|
2012-02-15 19:21
|
|
Maybe the patch fixes the random cmTryCompileExec problem. Now the problem is that the build always fails during the vtkTestExplicitInstantiation.cmake test. It seems that this test is not compatible with the patch, as "Run Build Command:c:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com EXPLICIT.sln /build Debug /project cmTryCompileExec" always fails with "Invalid project" (as described in comment 0028597).
Brad, could advise how to modify vtkTestExplicitInstantiation.cmake script or make the CMake patch compatible with this script? |
|
|
|
(0028604)
|
|
Andras Lasso
|
|
2012-02-16 09:42
|
|
I have good news!
With some small changes I've fixed the patch (see cmCoreTryCompile-2.8.7-rev02.patch). The problem was that the default targetName was set to "cmTryCompileExec" instead of NULL; this way when the user did not specify targetName then the "cmTryCompileExec" target attempted to be built instead of "ALL_BUILD". I've kept the randomization, but set default targetName to NULL, as it was before.
Most importantly: it seems that the randomization solved the random configuration failures. I've created an intensive test scenario (two parallel Slicer4 builds running in parallel with a configuration step continuously repeated for the cmcurl project). Without the patch the configuration problem occurred 4 out of 4 cases. With the patched CMake the configuration problem occurred 0 out of 4 cases. I'll repeat the test 6 more times with both the patched and the unpatched version to confirm the findings. |
|
|
|
(0028606)
|
|
Brad King
|
|
2012-02-16 10:17
|
|
|
Re 0012957:0028604: Great! I forgot when writing the patch that keeping targetName=0 in some code paths is necessary. OTOH in your patch the buffer goes out of scope while targetName still points at it. I fixed my original patch. Please try "0002-try_compile-Use-random-executable-file-name-12957.patch". |
|
|
|
(0028607)
|
|
Andras Lasso
|
|
2012-02-16 10:47
|
|
|
OK, thanks! I'll do all the further testing with 0002-try_compile-Use-random-executable-file-name-12957.patch and let you know the statistics. |
|
|
|
(0028614)
|
|
Andras Lasso
|
|
2012-02-17 10:10
|
|
I've completed 20 full Slicer4 builds (under heavy parallel load, on Win7 64-bit). The results:
* Without the patch: 1 successful, 9 failed
* With the patch: 10 successful, 0 failed
Based on this I'm confident that the patch fixes these random build problems and there doesn't seem to be any regressions.
Who would integrate the patch into the main branch? When we can expect to have a new release that includes this patch? |
|
|
|
(0028618)
|
|
Brad King
|
|
2012-02-17 11:58
|
|
|
|
|
(0030894)
|
|
David Cole
|
|
2012-09-03 16:02
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
16b1a6e4+0001-try_compile-Use-random-executable-file-name-12957.patch (2,316) 2012-02-13 10:07