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.
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.
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 <roger@xxxxxxxxxxxxxxxxx>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 > discussion.Hdf-forum@lists.hdfgroup.orghttp://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > Hdf-forum@xxxxxxxxxxxxxxxxxx > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > >
netcdfgroup archives: