Use dynamic multithreaded runtime library on windows

[Maxxen]

This fixes duckdb/duckdb-spatial#405

This was quite a journey to debug, and a lot of this windows stuff is new to me, but my understanding of the issue and the fix is that gyp on windows by default compiles node add-ons with a "static runtime library". This means that the native node add-on will not share the heap with any other dynamically loaded libraries (such as DuckDB extensions). When creating an R-Tree in the spatial extension, we hijack the query plan and instantiate a PhysicalCreateRTreeIndex operator, which is a subclass of the PhysicalOperator class present in DuckDB core. This thus gets allocated within the spatial extensions heap, but passed on and ultimately free'd within the DuckDB add-ons heap, causing a crash (?). My understanding is that the fact that we subclass across library boundaries is the key to why this crashes. A similar issue seems to be common when using the static runtime and templates defined in other libraries¹.

Note for the future: on debug builds these flags need to change to RuntimeLibrary: 3 and /MDd to link the debug dynamic library instead. e.g.

"msvs_settings": {
      "VCCLCompilerTool": {
          "RuntimeLibrary": 3,
          "ExceptionHandling": 1, 
          "AdditionalOptions": [
              "/bigobj", 
              "/GR",
              "/MDd"
          ]
      }
  }, 

But we don't seem to support separate debug and release targets in this add-on anyway sooo ¯\(ツ)/¯

Some other related threads:

• Need better /MD multithreaded dll support nodejs/node-gyp#330
• Windows build of Node.js is using a static C runtime which leads to having separate heaps for its addons nodejs/node#40926
• Update documentation for RuntimeLibrary [help required] (was: How do I set the RuntimeLibrary to /MT (MT_StaticRelease)?) nodejs/node-gyp#1686

Footnotes

1. https://stackoverflow.com/questions/35310117/debug-assertion-failed-expression-acrt-first-block-header ↩

[carlopi]

Amazing, thanks a lot!