Native addon seems to use Node.js included openssl version instead of my own, but only on Node.js 10 #1559
Comments
|
After more investigation, this is probably the same problem mentioned here: nodegit/nodegit#1490, to be more exact, on this comment: nodegit/nodegit#1490 (comment) Other issues that seems to be related to this problem I'm having: |
I'm assuming you mean that is _doesn't" feel right, yes? |
|
@refack yep! Just fixed it, thanks.
Exactly I just used
outputMicrosoft (R) COFF/PE Dumper Version 14.10.25019.0 Copyright (C) Microsoft Corporation. All rights reserved. |
Yes, node embbeds and exports the full openSSL library. From a design perspective to me it actually makes sense to reuse it. Otherwise you get two different copies of the library loaded to your process... |
|
Thank you for taking some time to look into this @refack, if I can help in any way let me know. |
|
@JCMais Problem solved? I need some help too.... I compiled library on Windows and Linux. They works. After i compiled node addon with node-gyp. {
"targets": [
{
"target_name": "cryptowrap",
"sources": [ "libcryptowrap.cc" ],
"cflags!": [ "-fno-exceptions" ],
"cflags_cc!": [ "-fno-exceptions" ],
"conditions": [
['OS=="win"', {
'include_dirs': [
"<!(node -e \"require('nan')\")",
'<(module_root_dir)/deps/include'
],
'msvs_settings': {
'VCCLCompilerTool': {
'AdditionalOptions': [ '/EHsc' ]
}
},
'conditions': [
['target_arch=="ia32"', {
'libraries': [
'<(module_root_dir)/deps/win/x86/libcryptowrap.lib',
'<(module_root_dir)/deps/win/x86/libcrypto-1_1.lib'
],
'copies': [{
'destination': '<(PRODUCT_DIR)',
'files': [
'<(module_root_dir)/deps/win/x86/libcryptowrap.dll',
'<(module_root_dir)/deps/win/x86/libcrypto-1_1.dll',
]
}]
}],
['target_arch=="x64"', {
'msvs_configuration_platform': 'x64',
'msbuild_toolset': 'v141_xp',
'libraries': [
'<(module_root_dir)/deps/win/x64/libcryptowrap.lib',
'<(module_root_dir)/deps/win/x64/libcrypto-1_1.lib'
],
'copies': [{
'destination': '<(PRODUCT_DIR)',
'files': [
'<(module_root_dir)/deps/win/x64/libcryptowrap.dll',
'<(module_root_dir)/deps/win/x64/libcrypto-1_1.dll',
]
}]
}]
]
}],
['OS=="linux"', {
'include_dirs': [
"src",
"<!(node -e \"require('nan')\")",
'<(module_root_dir)/deps/include'
],
'ldflags': [
'-Wl,-R<(module_root_dir)/deps/linux',
'-L<(module_root_dir)/deps/linux'
],
'conditions': [
['target_arch=="ia32"', {
'libraries': [ '-lcryptowrap' ]
}],
['target_arch=="x64"', {
'libraries': [ '-lcryptowrap' ]
}]
]
}]
]
}
]
}After i call my function in node via addon from libcryptowrap.dll and custom libcrypto.dll in Windows. And it's all fine. On Linux Node call openssl functions from her dependencies, not from custom libcrypto.so. What should I change on Linux ? I want to call a function that uses functions from my library and custom libcrypto.so |
|
@Not4me I still have the issue, I have not found a workaround yet. |
|
@JCMais Why all work on Windows 10 with my files, but work in linux. How i can recompile node without shared openssl? |
|
I created custom openssl with some my functions. Recompile nodejs with custom openssl. Now it works fine for me |
|
I'm having the same kind of problem. I have tried compiling the same system level OpenSSL version as a static library, then linking it directly into my shared library "A". It appears to work when I use "A" in any non-NodeJS applications. However, when I use library "A" in my node addon with node versions 10.x+, I get segfaults because the build seems to prefer the OpenSSL symbols in the node binary over my shared library "A", even within the shared library "A". I really think NodeJS should NOT export OpenSSL symbols:
I have my original issue here |
|
So I've some updates. I upgraded Turns out that Node.js does not export the whole OpenSSL library, but just a subset of it, I've opened the following issue on Node.js repo asking how to specify new symbols to be exported: nodejs/node#23293, and made a PR exporting the new ones here: nodejs/node#23344 But even with that, older versions would still not have those symbols, so my idea was to basically build OpenSSL anyway, using a similar OpenSSL version ( The error this time was related to more symbols not being defined, however the cause was different now. The OpenSSL version I was trying to compile were including files that didn't have the symbols it expected them to have, and the motive for that was because node-gyp adds the directory The TLDR here is that everything seems very |
|
I'm closing this because ultimately it's not a node-gyp issue. It's been discussed at length at nodejs/node and nodejs/help, see the linked issues. |
I have a Node.js bindings for libcurl, and currently I'm trying to fix an issue that I cannot find a solution, even tho I'm building OpenSSL directly, as see here and here, the version being used at runtime is the one bundled with Node.js. This seems to occur only on Windows.
The version set as dependency is
1.0.2o:https://github.com/JCMais/curl-for-windows/tree/445e537cb2f5656e3a3ede09e9e4782a6b62c299/openssl
However, by building the addon, and running the following
I can see that the one being used is the same used in Node.js 10:
node -p process.versionsThis started happening only with Node.js 10, I've rechecked if this is really the case by going back to Node.js 8 and recompiling the addon there.
The js file prints:
node -p process.versionsThis is currently causing some segfaults, since libssh2 1.7, which is being used to build the addon, is not compatible with OpenSSL v1.1.0h, the one shipped with Node.js 10.
I know that if upgrade libssh2 to 1.8 the problem would be resolved, but I still think that there is something wrong there, since it does not feel right to use the OpenSSL from Node.js.
Also I think this section of the wiki is outdated: https://github.com/nodejs/node-gyp/wiki/Linking-to-OpenSSL#windows
Looks like the symbols are exported by Node now, even on Windows. See nodejs/node@b4d4fd9
I have tested on linux, and this problem does not happen. I used the following
Dockerfilefor that:This is probably something wrong I'm doing, but I would love some help, or guidance on what I should do to debug/fix this.
The text was updated successfully, but these errors were encountered: