The C ABI version script is ELF-only, so on macOS `libvllm.dylib` exports its httplib internals to an example that compiled the same header in a DIFFERENT layout

[localai-bot]

examples/video_studio/main.cpp includes the vendored httplib.h and links
vllm::shared. vllm_shared links vllm PRIVATE
(CMakeLists.txt:2654), so the example inherits neither
CPPHTTPLIB_OPENSSL_SUPPORT nor OpenSSL::SSL. It therefore compiles the
vendored header in the no-TLS layout while libvllm.so contains the same
header compiled in the TLS layout. CPPHTTPLIB_OPENSSL_SUPPORT is a
whole-header switch that changes the layout of httplib::Result and
httplib::ClientConnection, which is why a50c57d69 put the define on the
target rather than per file.

On ELF this is safe BY CONSTRUCTION, not by luck

cmake/vllm_export.map is

VLLM_ABI_1 { global: vllm_*; local: *; };

so every httplib symbol inside libvllm.so is local and cannot be
preempted by, or preempt, the example's own copy. The two layouts never meet.

The gap is the Apple leg

That version script is applied under if(UNIX AND NOT APPLE)
(CMakeLists.txt:2661), and the tree already records why: a linker version
script is a GNU-ld/ELF feature with no ld64 spelling, so "the macOS dylib
therefore exports its default symbol set" (CMakeLists.txt:2656-2660). ld64
uses -exported_symbols_list, which this build does not pass.

On macOS the C++ internals of libvllm.dylib are therefore exported, including
its httplib inline and template instantiations. Whether Mach-O weak-definition
coalescing can then bind the example's no-TLS httplib::Result code against the
dylib's TLS-layout definition, or the reverse, is unmeasured. If it can, the
symptom is a silently corrupted response object with a clean link and no
diagnostic anywhere — the same failure mode a50c57d69 avoided on the library
side.

What would close it

Either measure it on macOS and record that coalescing cannot cross this
boundary, or give vllm_shared an -exported_symbols_list on the ld64 leg so
the Apple build has the same guarantee the ELF build has by construction.
tests/CMakeLists.txt's capi_shared_exports_only_abi check is gated on the
same UNIX AND NOT APPLE condition, so it does not cover this either.

Severity

Low, and not a blocker. No macOS build here has been measured, video-studio is
an example rather than a shipped path, and the ELF leg — every CI lane and every
released Linux artifact — is provably unaffected. Found while fixing
#1531; recorded rather than
fixed because closing it needs a macOS host this row does not have.

[localai-bot]

A post-hoc review of the merged record (#1616) verified the substance of the macOS finding and confirmed two overstatements in .agents/specs/c-api-library.md that are worth correcting under this row.

1. :243-244 — the grep claim is false as written. It says a repo-wide grep for VISIBILITY_PRESET "returns exactly those two lines". It does not: VISIBILITY_INLINES_HIDDEN does not contain that substring, so the grep returns one CMake line plus the spec's own two prose lines. The correct search term is VISIBILITY.

2. :304-305 — contradicts the same spec 22 lines earlier. It claims "every CI lane and every released Linux artifact carries the version script". The two macos-15 lanes and the Windows lanes are CI lanes that do not, which the spec itself establishes at :243. The Linux half of the claim holds; the universal quantifier does not.

The verified substance is unchanged: CMakeLists.txt:2665 is if(UNIX AND NOT APPLE), vllm_shared's only source is the generated stub, the archive target carries no visibility property, release.yml:320,351 are the only macos-15 runners in the repo, and no other workflow builds the dylib on macOS.

Not re-derived: the 48 -> 9376 symbol measurement, which needs a build.