Символы не загружаются при динамическом связывании библиотеки wfdb с использованием node-gyp в macOS High Sierra

я пытаюсь создать динамическую библиотеку, имеющую зависимость от библиотеки 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;
}

заголовочный файл для этого идет как

#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

Привязка Гип это

{
"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" ]
}
]
}

После запуска проекта с восстановление узла. Я получаю следующий вывод.

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | 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

И динамическая библиотека создается в ./build/Release/wfdb-test.dylib

После поиска символов внутри сгенерированного файла dylib:

nm -a build/Release/wfdb-test.dylib

я получил

U dyld_stub_binder

который является символом cpp по умолчанию (я ожидаю больше символов здесь.). Может кто-нибудь, пожалуйста, помогите мне, где я иду не так.

Детали среды разработки:

os: mac OS High Sierra ( v10.13.6 )
node: v8.11.3
node-gyp: v3.8.0

6

Решение

Пожалуйста, прости меня, если это кажется глупым, но где функция main ()? Есть ли другая точка входа в код?

Можно ли написать программу без использования функции main ()?

Также с cflags! и cflags_cc! установить -fno-exceptions, возможно ли, что компиляция будет проходить до конца, не выбрасывая правильные исключения?

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

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]