With no pattern in place for versioning the
@sspringer I'm a bit confused by this statement, as elsewhere others (and you elsewhere) are saying they need to include
With no pattern in place for versioning the
@sspringer I'm a bit confused by this statement, as elsewhere others (and you elsewhere) are saying they need to include
Yes, you should re-distribute the CRT redistributable with the application in addition to the Swift runtime. The reason for this is that there is an implicit dependency on the VC runtime (that is the equivalent of libSystem or glibc on macOS or Linux respectively). Although, you could always redirect the user to install that from Microsoft if you wanted. The local packaging or dependency addition in winget packages avoids the need for the user to manually install that dependency.
You will see that this matches pretty well. You can select exactly those DLLs from the path that I mentioned.
Note that which DLLs (and other files) from Microsoft you not only should but also are allowed to distribute with an application depends on what Microsoft has to say about this. This concerns the distribution of your application as a ācomplete, portableā application, without the need to install anything. There are good arguments that an application should better be installed on Windows, and you could require the user to install the appropriate VS C++ Runtime in a separate step as @compnerd already mentioned. In all cases, the versions of the VS C++ Runtime DLLs have to match those from the Visual Studio installation that you used to compile your Swift program. The according DLLs from other Visual Studio installations could as well be in your path, as those DLL files differ by name.
Update: There is an inaccuracy in the above paragraph: Within a given installation of Visual Studio you could install different C++ Runtime versions, so at least to some degree they are independent of the Visual Studio versions, and we talk about the C++ Runtime versions of course.
Note that with Swift 5.7.2 the required Swift DLLs and ICU DLLs are being installed to:
%PROGRAMFILES%\swift
For the VS C++ Runtime DLLs see above.
It might also be worth trying to figure out if there's a simple way to determine what redistributable DLLs are being used when building with Swift when outside of a developer command prompt.
Unfortunately, there is no "simple" way, at least in the sense of "here is a one liner". It is generally quite straight-forward, if tedious. link -dump -imports <module> | findstr \\.dll
should identify the imported DLLs, but this needs the transitive closure technically. That will give you full set of DLLs that are in use, and reducing that down the msvcrt/msvcprt should be straightforward.
if VCToolsRedistDir is set (and we are in a Developer Command Prompt), are the VC support DLLs that Swift uses going to be in %VCToolsRedistDir%\[arch]\Microsoft.VC142.CRT
?
Hi all, summoning @compnerd and @sspringer to see if anything has changed DLL-wise with 5.8. I see dynamic ICU has been removed. Has anything else changed dependency-wise if loading a compiled swift DLL side by side with copied VCRedist and Swift DLLs (copied from "C:\Program Files\swift\runtime-development\usr\bin")
I'm running into an issue loading my swift 5.8 compiled DLL with side by side swift 5.8 dlls and vcredist (loaded via LoadLibraryEx) with only LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR set, when my 5.7.3 DLL loaded just fine. Getting a generic "The specified module could not be found." error.
Just as a disclaimer: I am not involved in the development here but have only given some info. ICU has been changed to static linking as reported in the according blog entry. Concerning the error maybe @compnerd can give some answer. Maybe it is because the vcruntime
module has been renamed to visualc
(also mentioned in the blog entry).
@compnerd: What about licensing issues, I think ICU uses the Unicode license so I think this license file should be part of the Swift distribution (?) and then what about Swift programs using static linking (not yet ready on Windows). Of course, I do not expect some ālegal determinationā on your part, but what do you think, and maybe what does the core team think about those issues. BTW also about the Apache 2.0 license for Swift, does this have to be mentioned for Swift programs or is it just for the distribution of the Swift projects and not for Swift programs. I did not see any clear statement about this.
Not that I can think of off the top of my head.
Interesting. I don't think that is expected, perhaps +sls
would help? ( Show loader snaps - Windows drivers | Microsoft Learn)
I like the idea of including the license file in the packaging. Would you be willing to help with arranging this? We should be able to install the file into usr\share\docs
. We should be able to do this with the runtime which would mean that anyone using the runtime redistributable implicitly gets it redistributed, which might make it easier?
IANAL, so this is definitely stretching my knowledge (quite) a bit. I think that because the dependency is indirect and the runtime could package the license file, so it should be just a matter of the application bundling up all the files in the redistributable. Please apply a generous helping of salt, this is not my area of expertise.