openharmony/third_party_vulkan-loader
1
0
Fork 0
mirror of https://github.com/openharmony/third_party_vulkan-loader.git synced 2026-07-21 04:25:25 -04:00
Code Issues Packages Projects Releases Wiki Activity

docs: Update static linking info

Browse Source 
When static linking was removed as a build option, the documentation
for it was not ammended. This commit changes the text to describe that
it used to be supported, is no longer supported, and why the feature
was removed.

Change-Id: I8da0c1c811be7e9dc5119c4c27c34a5cbb30edf8
This commit is contained in:
Charles Giessen
2020-09-29 14:00:21 -06:00
committed by Charles Giessen
parent aa5b9e93d7
commit 552516eae4
1 changed files with 9 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
loader/LoaderAndLayerInterface.md
+9 -11
View File
@@ -330,20 +330,18 @@ be completely sure that a loader is present, they can include a loader or
runtime installer with their application.
###### Static Linking
The loader can also be used as a static library (this is shipped in the
Windows SDK as `VKstatic.1.lib`). Linking to the static loader means that the
user does not need to have a Vulkan runtime installed, and it also guarantees
that your application will use a specific version of the loader. However, there
are several downsides to this approach:
In previous versions of the loader, it was possible to statically link the loader.
This was removed and is no longer possible. The decision to remove static linking
was because of changes to the driver which made older applications that statically
linked unable to find newer drivers.
- The static library can never be updated without re-linking the application
- This opens up the possibility that two included libraries could contain
Additionally, static linking posed several problems:
- The loader can never be updated without re-linking the application
- The possibility that two included libraries could contain
different versions of the loader
- This could potentially cause conflicts between the different loader versions
As a result, it is recommended that users prefer linking to the dynamic
versions of the loader.
- Could cause conflicts between the different loader versions
The only exception to this is for macOS, but is not supported or tested.
##### Indirectly Linking to the Loader
Applications are not required to link directly to the loader library, instead