Hi Roel,
On Mon, Jun 10, 2013 at 9:30 AM, Roel Vanhout <[email protected]> wrote: > ** > 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? > Yes. Shared libraries do this, not static libraries. There is no shared state between static libraries. The slide with the dashed lines (slide 5, 4 if you ignore the title slides - I should have numbered them!) is incorrect. > > 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). > The sample code on that page (I switched it to VS2012 - http://msdn.microsoft.com/en-US/library/ms235460(v=vs.110).aspx) has you build an library and an executable that uses it. It says: "The DLL and .exe file are built with /MD, so they share a single copy of the CRT. If you rebuild with /MT so that they use separate copies of the CRT, running the resulting test1Main.exe results in an access violation." /MT statically links to the CRT, so the example in your link explicitly shows that the runtime state is not shared, even when everything is being built by the same compiler at the same time. Also, from this link ( http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.110).aspx): "Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT." Granted, this page talks about dlls, but that's usually what people are building on Windows. > > 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. > Your picture of static linkage is incorrect. Libraries are fully linked with the CRT at creation and each executable or library has a separate state due to the code being duplicated. Static CRT linking is no different than statically linking any other library. This is why building the example illustrated above with /MT causes issues. I'll agree that this is a confusing issue! Perhaps there is some enlightening text in my Windows system programming books. I'll check and get back to everyone. Cheers, Dana
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
