[tdlib] update to 1.8.63

[luadebug]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Just a bit validation of tdlib/td#3488

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[BillyONeal]

I think this is mergable as is but not pushing that button yet in case anything I cited here makes @luadebug decide they wish to change anything.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[vicroms]

AI review with some corrections done by me:

---

vcpkg CI Failure Report

Build: #130069
PR: #51103 — [tdlib] update to 1.8.63 by @luadebug
Result: failed | Finished: 2026-04-16T22:56:06Z

---

Summary

Triplet	Status	New Regressions	Known Failures
x64-windows	❌ Failed	1 (tdlib)	0
x64-windows-static	❌ Failed	1 (tdlib)	0
x64-windows-static-md	❌ Failed	1 (tdlib)	0
x86-windows	❌ Failed	1 (tdlib)	0
arm64-windows	❌ Failed	1 (tdlib)	0
arm64-windows-static-md	❌ Failed	1 (tdlib)	0
x64-windows-release	✅ Passed	0	0
x64-linux	✅ Passed	0	0
arm64-linux	✅ Passed	0	0
arm64-osx	✅ Passed	0	0
x64-android	✅ Passed	0	0
arm64-android	✅ Passed	0	0
arm-neon-android	✅ Passed	0	0

Total: 6 failed jobs, 1 unique regression (tdlib), all Windows triplets except x64-windows-release.

---

🔴 Regression: tdlib — Debug/Release Runtime Library Mismatch

Triplets: x64-windows, x64-windows-static, x64-windows-static-md, x86-windows, arm64-windows, arm64-windows-static-md
Failure type: BUILD_FAILED (linker error during debug build)

• Error:

  tl_writer_cpp.lib(tl_writer_td.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in generate_mtproto.cpp.obj
  tl_writer_cpp.lib(tl_writer_td.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in generate_mtproto.cpp.obj
  tl_writer_cpp.lib(tl_writer_td.cpp.obj) : error LNK2001: unresolved external symbol __imp__CrtDbgReport
  td\generate\generate_mtproto.exe : fatal error LNK1120: 1 unresolved externals
  

• Root cause: During the debug build, tdlib's code generation executables (generate_mtproto.exe, generate_common.exe) are linked against tl_writer_cpp.lib which was compiled with debug runtime (MDd/_ITERATOR_DEBUG_LEVEL=2), while the generator source files (generate_mtproto.cpp, generate_common.cpp) were compiled with release runtime (MD/_ITERATOR_DEBUG_LEVEL=0). This is a classic debug/release CRT mismatch.

  The tdlib build system builds host tools (code generators) as part of the main build. When vcpkg builds the debug configuration, these host tools should be built with consistent compiler flags, but something in tdlib's CMake is mixing debug libraries with release-compiled objects.

• Why x64-windows-release passes: The release-only triplet never builds a debug configuration, so the mismatch never occurs.

• Why Linux/macOS/Android pass: The runtime library mismatch check (LNK2038) is MSVC-specific. GCC/Clang don't enforce debug/release ABI compatibility at link time in the same way.

• Suggested fix: The tool executables (code generators) only need to run at build time and don't need a debug build. Use OPTIONS_RELEASE in the vcpkg_cmake_configure() call to restrict tool building to the release configuration:

  vcpkg_cmake_configure(
      SOURCE_PATH "${SOURCE_PATH}"
      OPTIONS
          ...
      OPTIONS_RELEASE
          -DTD_GENERATE_TOOLS=ON
      OPTIONS_DEBUG
          -DTD_GENERATE_TOOLS=OFF
  )

  This avoids the debug/release CRT mismatch entirely by only building the generators during the release pass (where all objects use consistent release flags). The generated code output is configuration-independent, so running generators only in release is sufficient. Check the upstream CMake for the exact option name controlling tool generation.

---

ℹ️ Notes

• This is a draft PR validating an upstream tdlib change (Enhance pkg-config generation for interface libraries and Windows compatibility tdlib/td#3488)
• The port updates from the current version to 1.8.63, using a specific commit ref (f06b0bac65278b03d26414c096080e7bfecfef52)
• The tdlib_core feature test also fails with the same root cause
• Other failed ports in the artifacts (libxt, moos-core, openslide) are pre-existing baseline failures unrelated to this PR
• Linux, macOS, Android, and all ARM triplets pass — the issue is Windows-specific (debug build only)

[luadebug]

I think this is mergable as is but not pushing that button yet in case anything I cited here makes @luadebug decide they wish to change anything.

Thanks. Should be good to go I think. @BillyONeal

[BillyONeal]

Thanks!