mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
No description
6cccafd1d0
The module preflight added with #1572 turned master red on Windows because none of the three modules smoke.conf configures could load there. Two independent causes; fixing either alone left the run red. 1. comsys and mail built as comsys.dll / mail.dll, while modules/Makefile.am builds comsys_mod.so / mail_mod.so. `cf_module` resolves `module <name>` to `.\bin\<name>.dll` or `./bin/<name>.so`, so no single config line could name those two modules on both platforms. The vcxproj files were taking their default TargetName; they now set it explicitly. Renaming the Windows side rather than the Unix side because those two DLLs had no DCL_EXPORT until #1569 and so were never loadable on Windows at all -- nothing can depend on the old names, whereas Unix installs use _mod today. 2. exp3 -- whose name already matched on both platforms -- still did not load, silently, and only under muxscript. LoadLibrary() does not treat a relative path as relative to the current directory: it appends the whole relative path to every entry in the DLL search order. The current directory is one of those entries until something calls SetDllDirectory(), which removes it. muxscript calls it in init_com() so engine.dll can find libmux.dll, and cf_module hands LoadLibrary ".\bin\<name>.dll" -- so under muxscript that resolved nowhere. netmux never calls SetDllDirectory(), which is why the identical config worked there and the divergence looked inexplicable. ModuleLoad now resolves the path against the current directory itself, which is what every caller already assumed. Both smoke gates go back to unconditional. They were made advisory on Windows only because the platform could not comply; it can now. Verified on Windows Server 2022, MSVC 14.51, Release x64: all three modules report (loaded) under muxscript from a clean environment, netmux logs "Comsys module loaded" / "Mail module loaded" with the new names, and the preflight passes silently in the smoke run. Measured, and worth recording for #1589/#1614: with the modules finally live on Windows, the suite returns exactly what it returns without them -- 1555 succeeded, 5 failed, same five, same one-verdict deficit. The five are a pre-existing configuration gap (autoconf-win32.h has no HAVE_LIBSSL and no reality levels), not a regression, and they are identical with SMOKE_OMIT_MODULES set. The corpus still cannot tell the two implementations apart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| client | ||
| color | ||
| debian | ||
| docker | ||
| docs | ||
| hooks | ||
| mux | ||
| parser | ||
| ragel | ||
| sgp | ||
| specs | ||
| testcases | ||
| tests | ||
| tools/worldbuilder | ||
| unix | ||
| utf | ||
| win32 | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| dounix.sh | ||
| dowin32.sh | ||
| GEMINI.md | ||
| LICENSE | ||
| Makefile | ||