Rename the static library on Windows.#40
Conversation
"version.lib" is in the Windows SDK and provides Windows functions like `GetFileVersionInfo`. After we added a `libversion` port to vcpkg, we now see other ports fail to build as a result of this conflict. See for example: ```console SDL2-staticd.lib(SDL_windowskeyboard.c.obj) : error LNK2019: unresolved external symbol GetFileVersionInfoSizeA referenced in function IME_GetId SDL2-staticd.lib(SDL_windowskeyboard.c.obj) : error LNK2019: unresolved external symbol GetFileVersionInfoA referenced in function IME_GetId SDL2-staticd.lib(SDL_windowskeyboard.c.obj) : error LNK2019: unresolved external symbol VerQueryValueA referenced in function IME_GetId ``` microsoft/vcpkg#48066 The .pc file seems to only ever select a static version, so I used the static output name there.
Applies repology/libversion#40 as a patch. See Windows SDK conflict from new port: microsoft#48066 Under https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#do-not-rename-binaries-outside-the-names-given-by-upstream I want to give upstream a chance to merge this.
|
Sorry, I don't feel like accumulating hacks for windows here. The right place for these would be in windows package managers. |
To be clear, this isn't a Windows package conflicting with another Windows package. This is libversion conflicting with the Windows SDK. It's a conflict for all Windows customers, not only those using a package manager. Normally we won't patch a library to rename it like this when upstream disagrees with it, so I think that leaves our only choice for vcpkg to either remove libversion from the index, or mark it |
See discussion: * repology/libversion#40 * microsoft#48176
"version.lib" is in the Windows SDK and provides Windows functions like
GetFileVersionInfo. After we added alibversionport to vcpkg, we now see other ports fail to build as a result of this conflict. See for example:microsoft/vcpkg#48066
The .pc file seems to only ever select a static version, so I used the static output name there.