【问题标题】:Can't run node.js module mdns in node webkit application无法在 node webkit 应用程序中运行 node.js 模块 mdns
【发布时间】:2014-09-16 01:27:27
【问题描述】:

我有一个节点 webkit 应用程序,它使用 mdns 模块从 Mac(使用 Mavericks)发布 Bonjour 服务。当我使用node server.js 运行服务器代码时,一切正常,但是在运行使用相同服务器代码的节点 webkit 应用程序时,我收到此错误:

"Uncaught Error: dlopen(/Users/me/myfolder/node_modules/mdns/build/Release/dns_sd_bindings.node, 1): no suitable image found.  Did find:
    /Users/me/myfolder/node_modules/mdns/build/Release/dns_sd_bindings.node: mach-o, but wrong architecture", source: /Users/me/myfolder/node_modules/mdns/lib/dns_sd.js (35)

显然,当您使用 npm 安装 mdns 模块时,它是为 x86 架构构建的,我需要它用于 i386,因为 node-webkit 是为 i386 构建的(我通过阅读此线程发现了这一点:@987654321 @)。您可以通过在终端中运行它来验证它:

$ lipo -info /Applications/node-webkit.app/Contents/MacOS/node-webkit 
Non-fat file: /Applications/node-webkit.app/Contents/MacOS/node-webkit is architecture: i386

我发现此链接建议了一个解决方案:https://github.com/rogerwang/node-webkit/issues/296 用于另一个模块(节点代理)。建议的说明是:

I managed to build a 32-bit version of node-proxy as follows:
I installed nw-gyp 
I ran nw-gyp configure --target=0.3.6  
I edited the generated file nodeproxy.target.mk in the build directory by replacing -arch x86_64by -arch i386 
I ran nw-gyp build

但由于我不习惯手动构建节点模块,在按照说明进行操作时,我不清楚应该在哪个文件夹中运行这些步骤(我假设它位于 node_modules 内的模块文件夹中: a) 当我安装 nw-gyp 时,我没有让 nw-gyp 命令全局使用(我猜说明中缺少 -g 选项) b) 改用 gyp configure --target=0.3.6 给我一个错误,说没有选项 target c)我尝试跳过配置步骤(只是为了尝试)并且构建命令中断:

无法自动定位 src 目录。这是暂时的 将被删除的 Chromium 功能。使用--depth 作为解决方法。

但是当尝试使用 --depth 时(当然)它需要一个参数,我不知道该放什么。

那么...我应该如何构建 mdns 模块以将其与 node webkit 一起使用? (0.8.6版本或者0.10.0我都能适应)。

【问题讨论】:

    标签: node.js bonjour node-webkit mdns gyp


    【解决方案1】:

    我设法让它工作。

    由于我已经安装了mdns 模块,我已经在我的项目文件夹中的文件夹node_modules/mdns 中获得了模块的源代码。

    以下是我为 i386 架构构建 mdns 模块所遵循的步骤:

    1) 运行以下命令安装 nw-gyp:npm install -g nw-gyp
    2)进入你的node-webkit项目的node_modules/mdns文件夹
    3)运行nw-gyp configure --target=0.8.6(这个目标是你安装的node-webkit的版本)
    4) 最后运行nw-gyp build

    我收到了很多关于不推荐使用的功能的警告,但它构建良好,现在我的 node-webkit 应用程序可以成功发布 Bonjour 服务。

    不幸的是,这不是最好的解决方案,因为在常规 npm install 之后,下一个安装该项目的人将不得不这样做......但至少它可以让它工作。

    【讨论】:

      猜你喜欢
      • 2014-12-07
      • 1970-01-01
      • 1970-01-01
      • 2017-08-04
      • 1970-01-01
      • 2016-04-30
      • 2014-03-11
      • 1970-01-01
      • 2013-08-17
      相关资源
      最近更新 更多