Skip to content

ext/uri: Fix static build on Windows by defining LEXBOR_STATIC#22165

Open
luthermonson wants to merge 1 commit into
php:PHP-8.5from
luthermonson:fix/uri-lexbor-static-windows
Open

ext/uri: Fix static build on Windows by defining LEXBOR_STATIC#22165
luthermonson wants to merge 1 commit into
php:PHP-8.5from
luthermonson:fix/uri-lexbor-static-windows

Conversation

@luthermonson
Copy link
Copy Markdown

@luthermonson luthermonson commented May 28, 2026

Summary

ext/uri is always built statically and pulls in the bundled lexbor headers via /I ext/lexbor. On Windows, lexbor's LXB_API macro defaults to __declspec(dllimport) when LEXBOR_STATIC isn't defined. As a result, when PHP itself is linked statically (no DLL) on Windows, every lxb_* symbol referenced from ext/uri fails to resolve:

libphp.lib(php_uri.obj) : error LNK2019: unresolved external symbol
    __imp_lxb_url_parse referenced in function ...
... (one LNK2019 per lxb_* function reachable from ext/uri) ...

@luthermonson luthermonson changed the title Fix static ext/uri build on Windows by defining LEXBOR_STATIC ext/uri: Fix static build on Windows by defining LEXBOR_STATIC May 28, 2026
@TimWolla
Copy link
Copy Markdown
Member

I know nothing about Windows. Should / Must this be fixed in ext/lexbor instead?

PHP bundles lexbor as a static-only extension (ext/lexbor/config.w32
declares EXTENSION("lexbor", ..., false /* never shared */)). On
Windows, ext/lexbor/lexbor/core/def.h defaults LXB_API to
__declspec(dllimport) when LEXBOR_STATIC is not defined, which causes
LNK2019 unresolved external symbol errors for every lxb_* function
referenced from consumers (ext/uri today, potentially others later)
when PHP itself is linked statically without a runtime DLL.

Default LEXBOR_STATIC at the top of the vendored def.h so the
PHP-bundled copy is always static-API regardless of consumer. The
existing #ifndef-guarded block below this addition is preserved
verbatim so the change is functionally a no-op for callers that
already set LEXBOR_STATIC explicitly.

This is a vendor patch to a copy of upstream lexbor and will need to
be re-applied on the next lexbor upgrade (most recent was v2.7.0 per
8.5.6 NEWS); the patch is three lines and intentionally adjacent to
the existing LEXBOR_STATIC handling so it is unlikely to drift.
@luthermonson luthermonson force-pushed the fix/uri-lexbor-static-windows branch from dad77e8 to da128c4 Compare May 28, 2026 13:48
@luthermonson
Copy link
Copy Markdown
Author

I think your instinct is correct, i"m running a test right now with a change to lexbor and will report back

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants