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 On Monday, June 10, 2013 08:28:17 AM Dana Robinson wrote: Hi Roel, Note that it says "...to link statically to the CRT _in a DLL_ unless...". Yes, linking the CRT statically into a DLL that is meant for redistribution is a bad idea. HOWEVER, that doesn't mean that static linking per se is bad. Linking a whole program statically (including the CRT) is a convenient way to make self-contained executables that can be distributed by just copying one binary around, that will not interfere with or depend on system-installed runtimes and that are portable across a large range of OS's, without having to wonder whether that OS has the right version of the CRT baked-in. Yes, this is convenient, but it is easy to create incorrect programs when you link several static libraries together when those libraries expose CRT objects. So, the original question, to have a static build option of HDF, is quite reasonable IMO (I have made my own Visual Studio projects in the past to do just that). The argument that static builds might be misused when they are linked into a DLL which will then go on and be used by programs that use a different version of the CRT doesn't seem like a very convincing argument to me, since (a) when doing builds with dependency chains this complicated, one should be building everything with the same version of the compiler anyway, and (b) there are many scenarios (scenarios that happen more than the dangerous one, IMO) where static building is perfectly safe. So, the following assertion “Personally, I'm not keen on making it easy for people to statically link to the CRT since it's a documented bad idea” is, I'd say, not quite true; it's only not recommended when doing so *in a DLL*, *and* when that DLL is then used by programs that use different versions of the CRT. This is not true. Even when each static library is built with the same compiler at the same time and in the same Visual Studio solution. The reason for this is that each static library is built as a separate entity, with its own CRT state. There is no "shared static state" going on unless you build one thing. Building three libraries and then building an executable that uses them is building four things, with four separate CRT states if they are each statically linked to the CRT. Copying the source code of said libraries into the same project as the executable and building THAT is one thing and then there is only one CRT state, but that is not what most people do. Static linking is only safe if the libraries do not expose CRT objects via the API. dll or lib, allocating in one CRT state and freeing in another results in heap issues. Cheers, Dana
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
