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.

Re: [netcdfgroup] [Hdf-forum] Make the Cmake Windows build staticplease !

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


  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: