Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am porting a project from linux to windows using cmake. The Project is clapack along with some testing procedures. Everything worked correctly when I built a 32 bit release. However when I build with the 64 bit compiler, the executables cannot be run.
The commands I run are:
cmake . devenv CLAPACK.sln /build
cmake "-DARCH=x86-64_Windows-7_VC10" -G "Visual Studio 10 Win64" devenv CLAPACK.sln /Rebuild "Release|x64" /project ALL_BUILD
I am running Windows 7 and cmake 2.8.4
Well, I don’t know how to run the tests, but the programs start just fine on my machine (I used the second
cmakecommand in the question, then opened the generated solution file in Visual Studio 2010 and built the entire solution). I’ll retry with 2010 SP1 as soon as the installer finishes.So here’s my output from building
RUN_TESTSin VS2010 SP1.xeigtstspassed no problem, butxeigtstzfailed repeatedly.The problem doesn’t resolve with a rebuild of that project. dumpbin says the PE header is valid.
When I run in the debugger, I most definitely get extensive debug output. Stack overflow. I’ll have to enable symbols to see exactly what’s going on. But first, let’s see if the Debug build fails the same way.
Yes, it does. The test case is seriously broken, it tries to use multiple megabytes of automatic variables, which don’t fit onto the stack. Here’s the main culprit:
The project has already been adjusted to use a stack of 10MB instead of the default 1MB. In the x64 build, this is still not enough. After changing the linker option to
/STACK:40000000, the crash is gone. (This is not a good solution, neither was the original expansion to 10MB a good idea. Don’t use ridiculously sized automatic variables, we have dynamic and static lifetimes for that.)After changing that test’s linker option: