(Exception for pre-compiled windows loaders) |
No edit summary |
||
| Line 6: | Line 6: | ||
Now, as to why those wrappers need to be pre-compiled, as opposed to our cross-compiling them with something like mingw. These wrappers are going to need to link against a C library for Windows (known as a CRT -- C-RunTime). Mingw does not contain a CRT.dll so if we were to compile the wrapper script using mingw, the CRT would need to be linked dynamically. Oftentimes, the script interpreters installed on Windows are statically linked to a specific CRT library. If the wrapper is dynamic, Windows will load the most recent CRT.dll that it has and then run it. When the wrapper tries to load the statically linked interpreter, the symbols from the CRT library that's embedded in the interpreter will conflict with the symbols provided by the dynamic CRT.dll. The wrapper and interpreter must both be statically linked to avoid this conflict. Since we cannot cross-compile in this manner with mingw, we need an exception to ship the upstream supplied pre-compiled binaries. | Now, as to why those wrappers need to be pre-compiled, as opposed to our cross-compiling them with something like mingw. These wrappers are going to need to link against a C library for Windows (known as a CRT -- C-RunTime). Mingw does not contain a CRT.dll so if we were to compile the wrapper script using mingw, the CRT would need to be linked dynamically. Oftentimes, the script interpreters installed on Windows are statically linked to a specific CRT library. If the wrapper is dynamic, Windows will load the most recent CRT.dll that it has and then run it. When the wrapper tries to load the statically linked interpreter, the symbols from the CRT library that's embedded in the interpreter will conflict with the symbols provided by the dynamic CRT.dll. The wrapper and interpreter must both be statically linked to avoid this conflict. Since we cannot cross-compile in this manner with mingw, we need an exception to ship the upstream supplied pre-compiled binaries. | ||
[[Category:Packaging guidelines drafts]] | |||
Revision as of 16:39, 17 October 2011
Exception for precompiled windows loaders
Windows does not support the shebang line like Unix systems do. For this reason, Windows has an idiom of creating wrapper executables for scripts. These wrappers check what name they were invoked under and then attempt to launch an interpreter with the script in question. For instance, a python loader may be called foo-app.exe. When run on Windows, it will try to run a python interpreter from the Windows PATH on the file foo-app.py in the same directory as the wrapper.
In some cases we may want to package software in Fedora which contains generic wrappers. The purpose here would be so that developers can create a script on Linux but package it up for use on Windows. The software package in Fedora would allow the developer to copy the generic wrapper into their software to run their script when installed on Windows. It therefore makes sense for us to ship those compiled wrappers in our package.
Now, as to why those wrappers need to be pre-compiled, as opposed to our cross-compiling them with something like mingw. These wrappers are going to need to link against a C library for Windows (known as a CRT -- C-RunTime). Mingw does not contain a CRT.dll so if we were to compile the wrapper script using mingw, the CRT would need to be linked dynamically. Oftentimes, the script interpreters installed on Windows are statically linked to a specific CRT library. If the wrapper is dynamic, Windows will load the most recent CRT.dll that it has and then run it. When the wrapper tries to load the statically linked interpreter, the symbols from the CRT library that's embedded in the interpreter will conflict with the symbols provided by the dynamic CRT.dll. The wrapper and interpreter must both be statically linked to avoid this conflict. Since we cannot cross-compile in this manner with mingw, we need an exception to ship the upstream supplied pre-compiled binaries.