Gyp help: Linking to built-in node openssl (and knowing when to)

[maxkorp]

A few questions with the new symbol exports for openssl on windows in 6.3.
Related issue in my project
Root gyp file
Internal gyp file
Relevant issue on core

I'm struggling with getting things to link properly. We currently link to our own openssl, but in windows this dies with 6.3. I've tried following the directions here (skipping the windows bit since those symbols are now exported), but it dies on all platforms with those changes.

So a few questions.

1. Supposing I was only worried about 6.3, how exactly would I go about getting this to work?
2. Realizing that ignoring everything before 6.3 is not an option, how would I conditionally do that? node_module_version is the same in 6.2 and 6.3, so that's not sufficient. I've been looking around to see what variables node-gyp provides, but I haven't found anything yet. Additionally, it seems like maybe I can link against the built in for older versions of node on not windows, so I'm not sure how I would structure that conditional. We also have to support electron, which doesn't export the symbols, so we definitely have to at least maintain the ability to use our local.
3. As an alternative, is there a flag I could use or something to prevent it from hitting those symbols and dying, (or perhaps an ordering I could change somehow via the gypfiles) and just keep linking to our own local?

Sorry for the small wall of text here, but I've been banging my head against this for a while, and I'm completely stumped.

[bnoordhuis]

Supposing I was only worried about 6.3, how exactly would I go about getting this to work?

It should mostly Just Work, really. If it isn't working, please post code and build output.

Realizing that ignoring everything before 6.3 is not an option, how would I conditionally do that?

1. Wait until v6 goes LTS and ordain that pre-LTS releases are unsupported and don't work.
2. Check the node version by shelling out in your binding.gyp. Not foolproof when cross-compiling.
3. Load symbols dynamically and fall back to your own openssl.dll when you can't load them from the main binary.
4. Add a flag to your binding.gyp that lets people building your add-on choose what to build and/or link against. Example: bnoordhuis/node-iconv@8d438cb

is there a flag I could use or something to prevent it from hitting those symbols and dying, [...] and just keep linking to our own local?

I think I covered that in the previous section. I'm not sure what you mean by "hitting those symbols and dying" - are you getting symbol clashes when building or loading the add-on?

All other things being equal, linking to your local copy of openssl will override any symbols that the node binary exports. If that doesn't work for you for some reason, again, please post code and build output. :-)

[saper]

@bnoordhuis Regarding "2. Check the node version by shelling out in your binding.gyp. Not foolproof when cross-compiling." don't you think we should have a config.gypi (I know I'm a bore) flag for that?

[bnoordhuis]

@saper Just a variable with the node version would not be enough, I think. It would not indicate if e.g. you're cross-compiling to electron.

[saper]

@bnoordhuis I was thinking like openssl_embedded true/false or something like that. Maybe even something more generic.

[bnoordhuis]

That exists, if I understand you correctly: node_shared_openssl, either 'true' or 'false'.