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: