2026年9月1日(火) 5:54 Stan Marsh <[email protected]>: > That is interesting. Some time back, someone (on either help-bash or > bug-bash) who was working on Windows with Cygwin stated that bash > loadables don't work in Cygwin. That poster never explained how or > why this was true, despite my efforts to get him to divulge details.
The default GCC toolchains of MSYS2 and Cygwin cannot create "POSIX shared objects" but can create shared objects in the form of Windows DLL, and the generated DLLs can be loaded by MSYS2/Cygwin's dlopen. However, the detailed behaviors of POSIX shared objects and Windows DLL are not exactly identical (in particular in symbol exposition and identification for dynamic linking). This means that a certain class of operations in a DLL works correctly, while some other operations might produce strange results. I'm not sure about the design of the GAWK extensions, but Bash lets loadable builtins directly access arbitrary symbols in the main executable image (functions and variables), which I think is the major source of the difficulty and confusion. With this design, even if one properly builds the main Bash (so that all symbols are explicitly exported by -Wl,--export-all-symbols) and the DLLs (with an implib generated by -Wl,-output-implib=libfoo.a), some strange behavior might happen depending on the detailed setup. For example, two instances of Bash images are created in a single process and the loadable builtin starts to communicate with the hidden instance of Bash ignoring the original Bash image.
