电子原生插件在Windows上失败 [英] Electron native addon failing on windows

查看:101
本文介绍了电子原生插件在Windows上失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个本地插件,该插件在未包装的电子应用程序上使用openSSL库. 在Windows 10上可以使用,在Windows 7上不能使用,我收到此消息:

I have a native addon that uses openSSL library on a unpacked electron app. On a windows 10 it works and on a windows 7 it's not working , I am receiving this:

    Error: The specified module could not be found.
    \\?\C:\Program Files (x86)\AppX Player\resources\app\src\addon\foo.node
        at Error (native)
        at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:167:20)

        at Object.Module._extensions..node (module.js:568:18)
        at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:167:20)
        at Module.load (module.js:458:32)
        at tryModuleLoad (module.js:417:12)
        at Function.Module._load (module.js:409:3)
        at Module.require (module.js:468:17)
        at require (internal/module.js:20:19)
        at Object.<anonymous> (C:\Program Files (x86)\AppX Player\resources\app\s
    rc\addon\index.js:11:3)

我针对电子的Windows ia32架构,并按如下所示对其进行了重建:

I am targeting a windows ia32 architecture for electron and I rebuild it like the following:

  node-gyp rebuild --target=1.3.1 --arch=ia32 --dist-url=https://atom.io/download/atom-shell --verbose

文件的绑定gyp如下所示,并且基于这个.它使用openSSL静态库

The binding-gyp of the file looks like this and is based on this. It uses the openSSL static library

{

            "targets": [
                {
                    "target_name": "addon",
                    "sources": [ 
                        "./src/encryptor.cpp" ,
                        "./src/EncryptorHandler.cpp",
                        "./src/SetupHandler.cpp",
                        "./src/RC4Handler.cpp",
                        "./src/HardwareInfoHandler.cpp",
                        "../Encryptions/RC4.cpp",
                        "../Encryptions/AES.cpp",
                        "../Encryptions/utils.cpp",
                        "../oggEncDec/src/FileHandler.cpp",
                        "../oggEncDec/src/OGGSelectiveEncryptor.cpp",
                        "../machineIdentification/common.cpp"
                    ],
                    "cflags!": [ "-fno-exceptions" ],
                    "cflags_cc!": [ "-fno-exceptions" ],
                    'cflags': ['-fexceptions'],
                    'cflags_cc': ['-fexceptions -Wall -Wextra -Wconversion'],
                    "include_dirs": [
                        "<!(node -e \"require('nan')\")",
                        "../"
                    ],
                    'conditions': [
                        ['OS=="linux"', {
                                "sources": [ 
                                    "../machineIdentification/linuxHardwareInfo.cpp"
                                ],
                                'libraries': [ 
                                    '-lcrypto',
                                ],
                            }
                        ],
                        ['OS=="mac"', {
                                "sources": [ 
                                    "../machineIdentification/macHardwareInfo.cpp"
                                ],
                                'libraries': [ 
                                    '-lcrypto',
                                ],
                        }],
                        ['OS=="win"', {
                            'msvs_settings': {
                                'VCCLCompilerTool': {
                                    'AdditionalOptions': [ '/EHsc' ],
                                    'ExceptionHandling': 1
                                }
                            },
                            "sources": [ 
                                "../machineIdentification/windowsHardwareInfo.cpp"
                            ],
                            'conditions': [
                                # "openssl_root" is the directory on Windows of the OpenSSL files.
                                # Check the "target_arch" variable to set good default values for
                                # both 64-bit and 32-bit builds of the module.
                                ['target_arch=="x64"', {
                                    'variables': {
                                        'openssl_root%': 'C:/OpenSSL-Win64'
                                    },
                                }, {
                                    'variables': {
                                        'openssl_root%': 'C:/OpenSSL-Win32'
                                    },
                                }],
                              ],
                              'libraries': [ 
                                '-l<(openssl_root)/lib/libeay32.lib',
                              ],
                              'include_dirs': [
                                '<(openssl_root)/include',
                              ],
                        }]
                  ]
                }
            ]
        }

以防万一缺少dll(它不应该像我链接静态库那样),我在exe的同一级别上添加了openSSL dll.还有什么可能导致这种行为?

Just in case it was a dll missing (it should not be as I was linking the static library) I added the openSSL dll on the same level of the exe. What else may be causing this behaviour?

修改 安装OpenSSL二进制文件可以正常工作,我认为静态链接可以解决这一问题,因此我不会依赖于外部dll的

Edit Installing OpenSSL binaries make it works, i thought the static linking would take care of that so I wouldn't depend on external dll's

编辑2 如果我可以打包静态库并将其捆绑在".node"文件中,那么一切都会解决.在.node文件上使用dependency walker告诉我它需要dll,而我需要的是在上面具有dll代码.

Edit 2 Everything would be solved if I could pack the static library and bundle it on the ".node" file. Using dependency walker on the .node file shows me that it is requiring the dll and what I need is for it to have the dll code on it.

推荐答案

http:/上显示lib /slproweb.com/products/Win32OpenSSL.html 似乎只是对仍在使用它的dll的包装. 我误以为node-gyp只是在编译东西而没有依赖关系,这是不正确的. 我在此处找到了另一个预编译的openssl库.

Turns out the lib on http://slproweb.com/products/Win32OpenSSL.html seems to be just a wrapper around the dll that still uses it. I misguided thought that node-gyp was just compiling the thing without the dependency which is not true. I found another precompiled openssl lib here that did the trick.

所以总结一下: 我需要在电子下使用OpenSSL运送某些东西,但电子不会像节点那样暴露OpenSSL并将其切换为borinSSL. 我遵循了tooTallNate的文章,该文章推荐了一个静态库,并假定该静态库是正确的,并且我以某种方式需要DLL,并且我假定node-gyp没有捆绑使用的静态库. 将lib换成另一个(或者最好自己编译)就可以了.

So to wrap up: I needed to ship something with OpenSSL under electron but electron does not expose OpenSSL like node does and switchs it for borinSSL. I followed tooTallNate article that recommended a static library and assumed the static library was right and I was somehow needing the DLL and I assumed node-gyp was not bundling the used static library. Switching the lib for another one (or better yet compiling it myself) did the trick.

这篇关于电子原生插件在Windows上失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆