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
>
>
