Due to differences in the way shared libraries work on Windows, plug-in .dlls end up linking against the shared HTSlib dll even if the executable includes the library in a static link. This results in there being two copies of the schemes global variable leading to a segmentation fault when the plug-in tries to register itself by calling hfile_add_scheme_handler.

This doesn't happen on UNIX-like systems because the run-time link resolves schemes to the one in the executable itself. On Windows, the executable initialises its copy, but the plug-in only sees the one in the dll, which never gets set up so the pointer is NULL.

Possible solutions:

• Only use dynamic links on Windows. As long as everything uses the same .dll the plug-in gets the right symbol.

• If hfile_add_scheme_handler finds that schemes is NULL on entry, try using dlopen/dlsym to locate the copy in the main executable and use that instead.