(Rewrite since it's about library usage only) |
(Formatting) |
||
| Line 10: | Line 10: | ||
{{admon/note||Longer version for its own page.}} | {{admon/note||Longer version for its own page.}} | ||
Software installers aimed at upstream developers may want to ship bits of code that can be used to install the upstream developers code on Windows or other operating systems. Sometimes these bits of code can be compiled from source using a cross-compiler like | Software installers aimed at upstream developers may want to ship bits of code that can be used to install the upstream developers code on Windows or other operating systems. Sometimes these bits of code can be compiled from source using a cross-compiler like MinGW. Other times, they cannot be shipped that way due to the limitations of Windows and MinGW. This page will explain how to tell the difference. In all cases, the upstream sources must ship with the source code for the binary; you just are allowed to ship from upstream's pre-compilation of that source in specific cases. | ||
The Windows dynamic library loader is a bit different from the Linux loader. It is capable of loading multiple versions of a library into a single process. One ramification of this is that some software may use one version of a library in its core but a library (or plugin) that it loads will use a different version. When this occurs, the application code has to be careful not to send data from its version of the library where the other version of the library may try to operate on it as if it was created by itself otherwise invalid access to memory or silent bugs may occur. This is especially bad with the Windows C library (known as the <b>CRT</b> -- C RunTime). If there are multiple versions of the <code>CRT</code>, simple things like stdout and stdin will fail to work since the FILE * handles for one of the versions will be attempting to write to the files opened by the other version and Windows will disallow that. | The Windows dynamic library loader is a bit different from the Linux loader. It is capable of loading multiple versions of a library into a single process. One ramification of this is that some software may use one version of a library in its core but a library (or plugin) that it loads will use a different version. When this occurs, the application code has to be careful not to send data from its version of the library where the other version of the library may try to operate on it as if it was created by itself otherwise invalid access to memory or silent bugs may occur. This is especially bad with the Windows C library (known as the <b>CRT</b> -- C RunTime). If there are multiple versions of the <code>CRT</code>, simple things like stdout and stdin will fail to work since the <code>FILE *</code> handles for one of the versions will be attempting to write to the files opened by the other version and Windows will disallow that. | ||
The latter has an especially problematic interaction with MinGW. MinGW does not provide a <code>CRT</code> since every current version of Windows ships with one. This means that when we cross-compile with MinGW, the application we create must be dynamically linked to the <code>CRT</code>. If we also link dynamically to other libraries then the application and the other libraries may ask the Windows loader to load two separate versions of the <code>CRT</code> and we'll run into the problems outlined above. | The latter has an especially problematic interaction with MinGW. MinGW does not provide a <code>CRT</code> since every current version of Windows ships with one. This means that when we cross-compile with MinGW, the application we create must be dynamically linked to the <code>CRT</code>. If we also link dynamically to other libraries then the application and the other libraries may ask the Windows loader to load two separate versions of the <code>CRT</code> and we'll run into the problems outlined above. | ||
| Line 19: | Line 19: | ||
==== Links ==== | ==== Links ==== | ||
* Microsoft post on using the CRT http://msdn.microsoft.com/en-us/library/ms235460%28v=VS.100%29.aspx | |||
* A developer's thoughts on working on this issue with Apache on Windows http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell | |||
[[Category:Packaging guidelines drafts]] | [[Category:Packaging guidelines drafts]] | ||
Revision as of 19:11, 17 October 2011
Exception for windows programs that link to unpackaged libraries
Short version
- If a package needs to ship Windows executables and those executables link to multiple windows DLLs that we don't ship, you may be allowed to ship the pre-compiled binary from upstream. See Precompiled Windows programs for details
Precompiled Windows programs
Software installers aimed at upstream developers may want to ship bits of code that can be used to install the upstream developers code on Windows or other operating systems. Sometimes these bits of code can be compiled from source using a cross-compiler like MinGW. Other times, they cannot be shipped that way due to the limitations of Windows and MinGW. This page will explain how to tell the difference. In all cases, the upstream sources must ship with the source code for the binary; you just are allowed to ship from upstream's pre-compilation of that source in specific cases.
The Windows dynamic library loader is a bit different from the Linux loader. It is capable of loading multiple versions of a library into a single process. One ramification of this is that some software may use one version of a library in its core but a library (or plugin) that it loads will use a different version. When this occurs, the application code has to be careful not to send data from its version of the library where the other version of the library may try to operate on it as if it was created by itself otherwise invalid access to memory or silent bugs may occur. This is especially bad with the Windows C library (known as the CRT -- C RunTime). If there are multiple versions of the CRT, simple things like stdout and stdin will fail to work since the FILE * handles for one of the versions will be attempting to write to the files opened by the other version and Windows will disallow that.
The latter has an especially problematic interaction with MinGW. MinGW does not provide a CRT since every current version of Windows ships with one. This means that when we cross-compile with MinGW, the application we create must be dynamically linked to the CRT. If we also link dynamically to other libraries then the application and the other libraries may ask the Windows loader to load two separate versions of the CRT and we'll run into the problems outlined above.
What this means for us is when the software we're packaging is intended to run on Windows end user's systems and the software links against multiple libraries then recompiling it locally will lead to code which may have errors when it finally gets to the Windows user's system simply because the code uses common functions from the C library. Shipping the upstream files which are built using a Windows native compiler and have statically linked to a CRT allows this software to run on Windows more reliably.
Links
- Microsoft post on using the CRT http://msdn.microsoft.com/en-us/library/ms235460%28v=VS.100%29.aspx
- A developer's thoughts on working on this issue with Apache on Windows http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell