NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I have implemented a CMake way of handling this issue in the 1_8_cmake branch of the hdf5 svn repository. In the root CMakeFiles.txt file I added an "include UserMacros.cmake" command that will load in an option and macro to change the flags to allow the use of /MT on windows. I also modified all the CMake code to enable a hook into the compile and link processes. The root UserMacros.cmake file is a placeholder for user-defined CMake code. The cmake code for the MT option is in the config/cmake folder under a new UserMacros folder in the file Windows_MT.cmake. Simply copy the contents of the Windows_MT.cmake file to the contents of the root UserMacros.cmake file, and enable the option. We would appreciate folks testing this out before we commit to the 1_8 branch. Allen On Monday, June 10, 2013 05:58:18 PM Dana Robinson wrote: Hi all, I stand corrected. I just created a test project and inspected the assembler for the output and it turns out that the CRT does share state when statically linked together. For example, this is what I get when I create a static library that calls free via a library function: foo_free: 0000000000000040: 48 89 4C 24 08 mov qword ptr [rsp+8],rcx 0000000000000045: 57 push rdi 0000000000000046: 48 83 EC 20 sub rsp,20h 000000000000004A: 48 8B FC mov rdi,rsp 000000000000004D: B9 08 00 00 00 mov ecx,8 0000000000000052: B8 CC CC CC CC mov eax,0CCCCCCCCh 0000000000000057: F3 AB rep stos dword ptr [rdi] 0000000000000059: 48 8B 4C 24 30 mov rcx,qword ptr [rsp+30h] 000000000000005E: 48 8B 4C 24 30 mov rcx,qword ptr [rsp+30h] *0000000000000063: E8 00 00 00 00 call free* 0000000000000068: 48 83 C4 20 add rsp,20h 000000000000006C: 5F pop rdi 000000000000006D: C3 ret It clearly just has a placeholder (highlighted line) that will be resolved when the final executable (dll or exe) is linked. As long as your application is a monolith, with no internal dlls at any level, the CRT issues should not exist. The linker will just copy in the static CRT code and all C library calls will resolve to that. Again, I stand corrected and I apologize for any confusion that I caused. I'll talk to Elena and Allen about what we can do to get this set up and document it. I'd still want it flagged as dangerous since I suspect it will burn a lot of people. Cheers, Dana
netcdfgroup
archives: