cpp-httplib: link Apple frameworks for CFHost resolver, add with_non_blocking_getaddrinfo option#30607
Open
andiwand wants to merge 2 commits into
Open
Conversation
The recipe unconditionally defines CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO, which compiles the CFHost-based asynchronous DNS resolver in getaddrinfo_with_timeout() on Apple platforms. That resolver references CoreFoundation and CFNetwork symbols (CFHostCreateWithName, CFRunLoopGetCurrent, CFRelease, ...), but the frameworks were only linked in the narrow macOS `_tls_enabled and use_macos_keychain_certs` case, and never for iOS/tvOS/watchOS at all. Any consumer without macOS keychain certs (or on a non-macOS Apple OS) failed to link with "Undefined symbols for architecture arm64". Link CoreFoundation and CFNetwork on every Apple OS via is_apple_os(), matching the unconditional define. Security stays scoped to the macOS keychain-certs case. The test_package now references the client request path so the resolver symbol is actually pulled in at link time (guarded so no network call is made), which reproduces the regression.
CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO enables the timeout-aware DNS resolver in getaddrinfo_with_timeout(); without it httplib falls back to plain blocking getaddrinfo() and ignores the resolution timeout. It is a robustness feature, not a functional requirement, yet it is what pulls in the platform-specific resolver dependencies: CoreFoundation/CFNetwork on Apple (CFHost) and libanl on glibc (getaddrinfo_a). Expose it as an option, default True to preserve current behavior. Setting it to False drops the define and those extra link dependencies for consumers that do not need DNS-phase timeouts.
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
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
Changes to recipe: cpp-httplib/all (applies to 0.28.0 and 0.47.0)
Motivation
On Apple platforms the recipe unconditionally defines
CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO, which compiles the CFHost-based asynchronous DNS resolver ingetaddrinfo_with_timeout(). That resolver referencesCoreFoundation/CFNetworksymbols (CFHostCreateWithName,CFRunLoopGetCurrent,CFRelease, ...), but the frameworks were only linked in the narrow macOS_tls_enabled and use_macos_keychain_certscase — and never for iOS/tvOS/watchOS at all.As a result, any consumer that builds without the macOS keychain-certs configuration, or that targets a non-macOS Apple platform, fails to link:
The existing
test_packageonly constructs ahttplib::Request, so it never references the resolver and did not catch this.Details
Fix the Apple framework linking. Link
CoreFoundation+CFNetworkon every Apple OS (viais_apple_os) whenever the non-blocking getaddrinfo path is compiled in;Securitystays scoped to the macOS keychain-certs case.test_packagenow references the client request path — guarded so no network request is made at runtime — so the resolver symbol is pulled in at link time and the regression is covered.Add a
with_non_blocking_getaddrinfooption (defaultTrue). That define is what pulls in the platform resolver dependencies:CoreFoundation/CFNetworkon Apple andlibanlon glibc. Without it,getaddrinfo_with_timeout()falls back to a plain blockinggetaddrinfo()and ignores the resolution timeout, so it is a robustness feature rather than a functional requirement. Defaulting toTruepreserves current behavior; consumers that do not need DNS-phase timeouts can set it toFalseto drop the define and the extra link dependencies.Tested locally with Conan on macOS/arm64 (apple-clang) for cpp-httplib/0.28.0 with: default options,
use_macos_keychain_certs=False(the previously failing configuration), andwith_non_blocking_getaddrinfo=False.