Skip to content

Addon is broken if building from source using an OpenSSL version different than the one used by Node.js #164

Closed
@JCMais

Description

@JCMais

It causes a segmentation fault, that is, when it does build.

This has been going on for some time, it's probably the cause of many issues: #130 #136 #137 #147 #160

Starting with Node.js 10 OpenSSL symbols were included on the Node.js lib, and the OpenSSL bundled with Node.js was bumped to 1.1.0.

I'm pretty sure this is the root cause of the current problems. Looks like the addon sometimes uses those instead of the ones from the OpenSSL it's compiled with. And since the version differs (the current version of the addon on npm, 1.3.3, is using 1.0.2o), it causes a segmentation fault.

One way to fix that was by upgrading OpenSSL so the versions match, however by doing so the build started to fail on pretty much all Node.js versions. node-gyp adds the OpenSSL headers folder used by Node.js as search folders during compilation, and they take precedence over the ones supplied by our own OpenSSL.

Besides that, Node.js didn't exported all OpenSSL symbols, just a subset of them, I've made this PR to try to allow the export of the ones required by libssh and libcurl: nodejs/node#23344

I've opened the following issue to try to track down how to correctly solve that since, currently, I do not have that much expertise with linking problems:
nodejs/node-gyp#1559
nodejs/help#1724

While no correct solution is pointed out, looks like I found a workaround: renaming the OpenSSL include folder that node-gyp adds to the list of search paths for header files, that way the ones inside the addon own OpenSSL takes precedence.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions