Skip to content

cpp-httplib: link Apple frameworks for CFHost resolver, add with_non_blocking_getaddrinfo option#30607

Open
andiwand wants to merge 2 commits into
conan-io:masterfrom
andiwand:cpp-httplib-apple-getaddrinfo-frameworks
Open

cpp-httplib: link Apple frameworks for CFHost resolver, add with_non_blocking_getaddrinfo option#30607
andiwand wants to merge 2 commits into
conan-io:masterfrom
andiwand:cpp-httplib-apple-getaddrinfo-frameworks

Conversation

@andiwand

Copy link
Copy Markdown
Contributor

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 in getaddrinfo_with_timeout(). That resolver references CoreFoundation/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.

As a result, any consumer that builds without the macOS keychain-certs configuration, or that targets a non-macOS Apple platform, fails to link:

Undefined symbols for architecture arm64:
  "_CFHostCreateWithName", referenced from:
      httplib::detail::getaddrinfo_with_timeout(...) in ...
  "_CFRunLoopGetCurrent", referenced from:
      ...
ld: symbol(s) not found for architecture arm64

The existing test_package only constructs a httplib::Request, so it never references the resolver and did not catch this.

Details

  1. Fix the Apple framework linking. Link CoreFoundation + CFNetwork on every Apple OS (via is_apple_os) whenever the non-blocking getaddrinfo path is compiled in; Security stays scoped to the macOS keychain-certs case. test_package now 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.

  2. Add a with_non_blocking_getaddrinfo option (default True). That define is what pulls in the platform resolver dependencies: CoreFoundation/CFNetwork on Apple and libanl on glibc. Without it, getaddrinfo_with_timeout() falls back to a plain blocking getaddrinfo() and ignores the resolution timeout, so it is a robustness feature rather than a functional requirement. Defaulting to True preserves current behavior; consumers that do not need DNS-phase timeouts can set it to False to 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), and with_non_blocking_getaddrinfo=False.


  • Read the contributing guidelines
  • Checked that this PR is not a duplicate: list of PRs by recipe
  • If this is a bug fix, please link related issue or provide bug details
  • Tested locally with at least one configuration using a recent version of Conan

andiwand added 2 commits July 11, 2026 09:30
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant