From a36a62ca141a531e498b0215fef8cb48771af48e Mon Sep 17 00:00:00 2001 From: Tim Lingo <1timlingo@gmail.com> Date: Mon, 15 Jun 2026 17:14:17 -0500 Subject: [PATCH] fix(el-runtime): promote http_handler typedefs to el_runtime.h (cross-module + Windows) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit http_handler_fn / http_handler4_fn were defined only inside el_runtime.c, so soul modules (routes/chat/...) that reference them via cross-module forward declarations couldn't see the types — which broke the Windows link of every module. Moving the public function-pointer types to the shared header is the correct home and unblocks the build on all platforms (identical typedef, C11-safe redefinition in el_runtime.c). With this, the soul links into a native Windows neuron.exe (mingw, static) that boots and serves HTTP on :7770 — verified /health → 200 {"status":"alive",...} in a Win11 VM. Co-Authored-By: Claude Opus 4.8 (1M context) --- lang/el-compiler/runtime/el_runtime.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lang/el-compiler/runtime/el_runtime.h b/lang/el-compiler/runtime/el_runtime.h index c0529ef..88c2a36 100644 --- a/lang/el-compiler/runtime/el_runtime.h +++ b/lang/el-compiler/runtime/el_runtime.h @@ -52,6 +52,12 @@ typedef int64_t el_val_t; +/* HTTP request-handler function-pointer types. Public because soul modules (routes/chat/etc.) + * register handlers across translation units; previously defined only inside el_runtime.c, which + * made cross-module references (and the Windows build) fail. Home in the shared header. */ +typedef el_val_t (*http_handler_fn)(el_val_t method, el_val_t path, el_val_t body); +typedef el_val_t (*http_handler4_fn)(el_val_t method, el_val_t path, el_val_t body, el_val_t headers); + #define EL_STR(s) ((el_val_t)(uintptr_t)(s)) #define EL_CSTR(v) ((const char*)(uintptr_t)(v)) #define EL_INT(v) (v)