在macOS High Sierra上使用node-gyp动态链接wfdb库时,不会加载符号

abh*_*ash 6 c++ dynamic-linking node.js missing-symbols node-gyp

我正在尝试创建一个依赖于WFDB库的动态库(https://www.physionet.org/physiotools/wfdb.shtml).我的c ++代码如下:

#include <stdio.h>
#include <iostream>
#include <vector>
#include <vector>
extern "C" {
    #include <wfdb/wfdb.h>
}

#include "./sample_wfdb.h"

int add(int a, int b){
    return a + b;
}

int read(){
    int i, nsig;
    WFDB_Siginfo* siarray;
    WFDB_Sample* v;
    nsig = isigopen("/data/100s", NULL, 0);
    if (nsig < 1)
        exit(1);
    siarray = (WFDB_Siginfo*)malloc(nsig * sizeof(WFDB_Siginfo));
    nsig = isigopen("data/100s", siarray, nsig);
    for (i = 0; i < nsig; i++)

        v = (WFDB_Sample*)malloc(nsig * sizeof(WFDB_Sample));

    if (v == NULL) {
        fprintf(stderr,"%s: insufficient memory\n");
        exit(2);
    }
    std::vector<int> signal1, signal2;
    for (int i = 0; i < siarray[0].nsamp; i++) {
        if (getvec(v) < 0)
            break;
        for (int j = 0; j < nsig; j++) {
            if (j == 0) {
                signal1.push_back(v[j]);
            }
            if (j == 1) {
                signal2.push_back(v[j]);
            }
        }
    }
    int sig_size = signal1.size();
    std::cout << sig_size << std::endl;
    return sig_size;
}
Run Code Online (Sandbox Code Playgroud)

这个头文件如下

#ifdef __linux__
  extern "C" int read();
  extern "C" int add(int x, int y);
#elif _WIN32
  extern "C" __declspec(dllexport) extern "C" int read();
  extern "C" __declspec(dllexport) int add(int x, int y);
#elif __APPLE__
  extern "C" int read();
  extern "C" int add(int x, int y);
#endif
Run Code Online (Sandbox Code Playgroud)

绑定.吉普是

{
  "targets": [
    {
      "target_name": "wfdb-test",
      "type": "shared_library",
      "libraries": [ "/usr/local/lib/libwfdb.10.6.0.dylib"] ,
      "sources": [ "sample_wfdb.cpp -lwfdb" ],
      "cflags!": [ "-fno-exceptions" ],
      "cflags": [ "-std=c++11" ],
      "cflags_cc!": [ "-fno-exceptions" ]
    }
  ]
}
Run Code Online (Sandbox Code Playgroud)

使用node-gyp rebuild运行项目时.我得到以下输出.

gyp info it worked if it ends with ok
gyp info using node-gyp@3.8.0
gyp info using node@8.11.3 | darwin | x64
gyp info spawn /usr/local/bin/python2
gyp info spawn args [ '/usr/local/lib/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',gyp info spawn args   '/Users/abhinashkumarjha/Desktop/cpp-codes/build/config.gypi',
gyp info spawn args   '-I',gyp info spawn args   '/usr/local/lib/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/abhinashkumarjha/.node-gyp/8.11.3/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/Users/abhinashkumarjha/.node-gyp/8.11.3',
gyp info spawn args   '-Dnode_gyp_dir=/usr/local/lib/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/Users/abhinashkumarjha/.node-gyp/8.11.3/<(target_arch)/nod
e.lib',
gyp info spawn args   '-Dmodule_root_dir=/Users/abhinashkumarjha/Desktop/cpp-codes',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  SOLINK(target) Release/wfdb-test.dylib
gyp info ok
Run Code Online (Sandbox Code Playgroud)

并在./build/Release/wfdb-test.dylib下生成动态库

在生成的dylib文件中查找符号时:

nm -a build/Release/wfdb-test.dylib
Run Code Online (Sandbox Code Playgroud)

我明白了

U dyld_stub_binder
Run Code Online (Sandbox Code Playgroud)

这是默认的cpp符号(我希望这里有更多的符号.).任何人都可以帮助我在哪里出错.

开发环境的详细信息如下:

os: mac OS High Sierra ( v10.13.6 )
node: v8.11.3
node-gyp: v3.8.0
Run Code Online (Sandbox Code Playgroud)

eri*_*erg 1

如果这看起来很愚蠢,请原谅我,但是 main() 函数在哪里?代码还有另一个入口点吗?

是否可以不使用 main() 函数来编写程序?

另外,还有cflags!和cflags_cc!设置为 -fno-exceptions ,是否有可能编译一直进行而不会抛出正确的异常?

https://blog.mozilla.org/nnethercote/2011/01/18/the-dangers-of-fno-exceptions/