build: fix iOS/macOS C-linkage on HCWebSocketOptions; Android compileSdk 34; Linux WSC dl/pthread; UWP ARM64; GDK asio#987
Merged
v-patrickpe merged 2 commits intoJun 5, 2026
Conversation
…libs Bundles three independent low-risk additions: Build/libHttpClient.Android/build.gradle Bumps `compileSdkVersion` from 31 to 34. Required by downstream consumers (Bumblelion) being upgraded to current AGP/Gradle. SDK bump only - no runtime API change. Samples/UWP-Http/Http.vcxproj Suppresses `TreatWarningAsError` for `Release|ARM64` to unblock ARM64 sample builds while a separate cleanup of the underlying warning is pursued. Build/libHttpClient.Linux/CMakeLists.txt Adds `\` to the `WebSocketCompressionTests.Linux` target_link_libraries so the test binary links cleanly. The WebSocket Compression support (#965) addition introduced an unresolved `dlopen`/`dlsym` reference via linked crypto in some agent configurations. This surfaced in downstream consumer pipeline PlayFab.SDKs.All TestDrop (Microsoft ADO def 137186) on 2026-05-28 after Linux clang/dpkg fixes unblocked the prior failure mode. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…rial-port on GDK Fixes two regressions surfaced by PlayFab.SDKs.All TestDrop run 148660743 against latest libHttpClient main (post #965 WebSocket Compression): 1) Include/httpClient/httpClient.h DEFINE_ENUM_FLAG_OPERATORS(HCWebSocketOptions) was placed inside the file-wide extern `"C"` block. The macro expands to inline operators returning HCWebSocketOptions&, which clang rejects under -Wreturn-type-c-linkage -Werror on Xcode iOS/macOS builds: error: 'operator|=' has C-linkage specified, but returns user-defined type 'HCWebSocketOptions &' which is incompatible with C Wrap only the macro call in extern `"C++"` so the operators get C++ linkage while the rest of the public surface stays C-linked. 2) Build/libHttpClient.GDK.props GDK builds compile with NOSERIALCOMM (no DCB struct), but asio (pulled in via websocketpp) tries to instantiate win_iocp_serial_port_service. Add ASIO_DISABLE_SERIAL_PORT to the GDK PreprocessorDefinitions; we never use asio's serial-port transport. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
rgomez391
reviewed
Jun 4, 2026
rgomez391
reviewed
Jun 4, 2026
rgomez391
approved these changes
Jun 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes 4 build regressions and 1 latent GDK build hazard surfaced by PlayFab.SDKs.All TestDrop build 148660743. TestDrop runs with
checkoutSubmodulesAsLatestCommit: true, so it builds libHttpClient main HEAD against PlayFab.SDKs.All's iOS/macOS/Linux/GDK toolchains — exposing platform regressions that this repo's MSVC-only PR CI does not catch.Why these weren't caught upstream
libHttpClient
libHttpClient.CI.ymlbuilds primarily on MSVC/Windows. clang-Wreturn-type-c-linkage(Xcode iOS/macOS) and the LinuxWebSocketCompressionTestslink (-ldl -lpthread) never gated PR #965. Captured as follow-up: AB#62563305.Commits
8c4efc0— Android compileSdk 34 + UWP ARM64 warning + Linux WSC dl libsBuild/libHttpClient.Android/build.gradle— compileSdk → 34 — AB#62563300Build/libHttpClient.Linux/CMakeLists.txt— adddl pthreadto WSC test link — AB#61359145Samples/UWP-Http/Http.vcxproj— ARM64 -W4/-Werror suppression — AB#625633012817f2e— iOS/macOS extern C++ wrap; GDK asio serial-port disableInclude/httpClient/httpClient.h(line 1046) — wrapDEFINE_ENUM_FLAG_OPERATORS(HCWebSocketOptions)inextern ""C++"" { }so the C++ operator overloads aren't inside the file-wideextern ""C""block (clang-Wreturn-type-c-linkage -Werrorreject) — AB#62563298Build/libHttpClient.GDK.props— addASIO_DISABLE_SERIAL_PORTto PreprocessorDefinitions; GDKNOSERIALCOMMremovesDCBwhich breaks asio'swin_iocp_serial_port_service(pulled in via websocketpp) — AB#62563299Repro (iOS/macOS)
Introduced by #965 (
b19d186) placing the macro inside the file-wideextern ""C"" {(opened L24, closed L1496). MSVC and gcc tolerate it; clang-Werrordoes not. Minimal fix preserves C linkage for the entire public API surface and only flips toC++for the 1-line macro expansion.Risk
extern ""C++""around a macro is standard C++; supported by MSVC/clang/gcc. No ABI impact — operator overloads were never callable from C.ASIO_DISABLE_SERIAL_PORTonly removes a transport we never use. No runtime behavior change. asio config knob atExternal/asio/asio/include/asio/detail/config.hpp:1066-1080.Validation
Pre-merge validated via PFSDKAll TestDrop build 148684233 (with this tip pinned as the libHttpClient submodule). All 4 in-scope fixes confirmed:
dl pthread— libHttpClient static builds cleanASIO_DISABLE_SERIAL_PORT— applies; full GDK still blocked separately on NuGet feed gapRelated ADO work items
dl/pthread(Raul)