Hi, > 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.
OK I understand your point now I think - to check that I do, can I ask, are you saying that when considering slide 4 in the deck you send earlier, you mean that even when all libraries are compiled with VS 2008, there still is no shared state between the runtimes? In that case, I don't think that's correct. Consider http://msdn.microsoft.com/en-US/library/ms235460%28v=vs.80%29.aspx and the other CRT-related pages linked on that page (this includes the page you linked to earlier). This page explicitly describes the situation 'when crossing DLL boundaries'. This does not include crossing 'static library' boundaries. To verify, I just made a simple .exe in VS2008 that uses 2 static libraries. In those libraries, I have one function each that accesses an environment variable as per the example in the page linked above. When I set the variable in a function in static library 1, then static library 2 can read that environment variable. That means, according to the descriptions on the MSDN website, that the CRT's are shared (I can send my project to anyone who wants to test, but it's really 5 minutes worth of work to make it yourself). My mental picture is as follows: there is one instance of the CRT per DLL that implements it. When the CRT dll is loaded, it allocates its heap, initializes tables with environment variables, etc. Now when the CRT is linked statically, that code doesn't get included yet in the .lib that is produced. It's the linker that will insert the CRT code and that code will be shared between all libraries that are linked in statically at that point in time. That static CRT will be initialized at the moment the application is started, and all functions in libraries that have been linked into that application will use the same heap, environment variables etc. > 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. Allocating memory in one instance of the CRT and then freeing it in another will cause heap corruption, yes, but I don't think (and as far as I can tell my test described above proves) that static libraries that have all been build by the same compiler version and are then all linked into an application, again by the same compiler, have separate CRT instances between them. One application with no DLL's = one CRT instance. (I'm not sure what happens when you link a static library build with a different version of VS, but I don't think we're concerned with that question here). cheers, roel ________________________________ From: Hdf-forum [mailto:[email protected]] On Behalf Of Dana Robinson Sent: Monday, June 10, 2013 15:28 To: HDF Users Discussion List Subject: Re: [Hdf-forum] [netcdfgroup] Make the Cmake Windows build staticplease ! 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
