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 On Mon, Jun 10, 2013 at 4:26 PM, Roger Martin <[email protected]>wrote: > Hi, > > Noting the MinGW64(4.8) style of building: just tried the cmake(2.8.11.1) > build approach for hdf5(1.8.11). Some gliches and I do appreciate the > effort of build tools such as cmake. > > I do try every now and then but fall back to building hdf5 and hdf5_hl by > selecting the sources in NetBeans projects and after blending/updating a > few config headers build it with the make files generated from NetBeans > > I suspect most developers(including me) since we're all busy don't give > feed back often enough. We get something working and don't have the time > to share experience. > > First thing with cmake build hit was the executable looking for a good > make. make's on windows has differences and I have a gmake of recent enough > that works so I pointed it to it. Get further then turn on parallel and > keep filling paths to openmpi libraries and cmake rejects for a bit and > then finally the right combination is hit and it is satisfied. > Configure done. > Generate done. > > gmake goes at building H5detect.exe and soon hit undefined reference to > '__imp_gethostname' > > Now as a developer I know my end code won't depend on this H5detect.exe so > I at this point just go back to building with my handy NetBeans make > scripts which build hdf5 with openmpi readily and I'm in business with hdf5 > 1.8.11 upgrade. Able to build window's dll's that aren't dependent on being > under cygwin; they are windows dll's > > Of course I take care of a couple of H5_HAVE_WIN32_API preprocessor > choices since mingw64 is closer to the !H5_HAVE_WIN32_API case. The > distinction of WIN32 is for me more a distinction of using Microsoft tool > chain. Instead my preference is portable compiler such as g++ 4.8. The > portion I had to break/comment out this time until I need it is the H5PL > plugin code > > > > > On 06/10/2013 01:28 PM, Allen Byrne wrote: > > One clarification - The CRT option IS a compiler flag, it's just simpler > to think of it as a link issue. > > > > Allen > > > > On Monday, June 10, 2013 08:56:14 AM Allen Byrne wrote: > > It seems to me that the discussions are not being specific enough with > which build/CRT configuration is discussed. > > > > In my opinion there are two CRT issues and two build issues: > > 1: Linking with static CRT(/MT) and linking with dynamic CRT(/MD). > > 2: Building static libraries and building dynamic libraries. > > > > Therefore there a four configurations of which we supply the cmake code > and binaries for the two build configurations with just the dynamic CRT. > > > > Allen > > > > > > > _______________________________________________ > Hdf-forum is for HDF software users > [email protected]http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > >
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
