Conversation
This fix works but I wonder if it would be better to install the latest zlib version for vtquery to use rather than depending on whichever version node.js statically links to? Maybe there's a way to relink zlib for node.js? If this is more trouble than it's worth, I'd say let's move forward with this change. |
How can we have the module use |
I've tried this and its doable but dangerous, since the zlib version changes in node.js and may (rarely) change ABI. Long story/no link on this currently however, sorry.
There is not. Depending on the symbols dynamically is the only way that I'm aware of.
Yes, I think this change is the best solution. However another very interesting one (longer term) is mapbox/gzip-hpp#25. That would allow us to not use libz and not have this challenge of trying to adapt to the statically linked libz. Instead we'd use libdeflate and control our version and hopefully be faster in the process. |
It is, the option is just different on linux: |
As part of the PR review of #95, @alliecrevier ask why we explicitly link to libz (which is https://zlib.net/).
I tested without explicit linking and things work fine, so I think we don't need this and it was my mistake to add.
The reason this works (without explicit linking) is that:
-undefined dynamic_lookup(on OS X) andrdynamic(on linux) such that any missing symbols do not prevent the linker from working. The idea is that the module is linked without full symbol resolution and then any missing symbols are expected to be resolved at runtimeRemoving this actually fixes the docker build which I noticed was failing since it was looking for
libzand could not find it: