#c #node.js #node-gyp
#c #node.js #узел-gyp
Вопрос:
Я решил написать собственный модуль для Node, используя компилятор VS2015 и node-gyp под Windows 8.1 32bit. Я работал с инструкциями с этой страницы. Я искал в Интернете (включая StackOverflow) в поисках решения моей проблемы.
Я использую следующие версии:
- Узел: 4.6.0
- Node-gyp: 3.4.0
Исходный код модуля:
// main.c
#include <node.h>
#include <v8.h>
void Method(const v8::FunctionCallbackInfo<v8::Value>amp; args) {
v8::Isolate* isolate = args.GetIsolate();
v8::HandleScope scope(isolate);
args.GetReturnValue().Set(v8::String::NewFromUtf8(isolate, "world"));
}
void init(v8::Local<v8::Object> target) {
NODE_SET_METHOD(target, "hello", Method);
}
NODE_MODULE(sapphire, init);
// binding.gyp
{
"targets": [
{
"target_name": "sapphire",
"sources": [ "main.c " ]
}
]
}
Каждый раз компиляция ( node-gyp rebuild
вызываемая внутри папки исходного кода аддона) завершается успешно. Перед компиляцией Node-Gyp выводит данные, для которых выполняется компиляция node@4.6.0 | win32 | ia32
. До этого момента все выглядело хорошо.
Для теста я написал самый простой из возможных сценариев.
// test.js
try {
var sapphire = require('/build/Release/sapphire');
console.log(sapphire.hello());
} catch(err) {
console.log(err);
}
В результате была напечатана ошибка Error: Module did not self-register.
. Я попытался заменить Node и V8 на NAN (следуя этому руководству). Но результат был тот же самый.
Во время поиска решения моей проблемы я столкнулся с двумя возможными причинами:
- Неправильные версии (библиотеки по сравнению с интерпретатором). К сожалению, исключена эта возможность, Node-Gyp явно использует версии библиотеки те же, что и интерпретатор, который я использую.
- Повторно загрузите модули из node_modules . Я, честно говоря, не понимаю, почему. Все необходимые модули были обновлены во время установки Node-Gyp, остальное не имеет значения.
Что может вызвать эту ошибку? Исходный код модуля был загружен из руководства из документации для узла (версия 4.6.0). Я также попытался внести небольшие изменения и использовать всевозможные неофициальные руководства, включая NAN. Каждый раз проблема одна и та же.
Комментарии:
1. ‘.c ‘ не является распространенным расширением файла для исходных файлов c . Мне интересно, может ли изменение расширения файла на что-то вроде «.cc» вместо этого помочь, поскольку я видел, как node-gyp выбирает другой компилятор (c против c ) на основе расширения файла и других подобных вещей.
2. @mscdex Я не могу в это поверить. Ты прав! Я был убежден, что в конечном итоге расширение ничего не меняет. Теперь это работает отлично! Перепишите это как ответ, если сможете.
Ответ №1:
node-gyp (инструмент, используемый для создания дополнений к узлам) имеет тенденцию делать некоторые предположения, по крайней мере, когда дело доходит до компиляции ваших исходных файлов. Например, он автоматически выберет «правильный» компилятор на основе расширения исходного файла. Поэтому, если у вас есть файл ‘.c’, он использует компилятор C, а если у вас есть файл ‘.cc’ (или, возможно, файл ‘.cpp’), он использует компилятор C .
‘.c ‘ не является общим расширением файла для исходных файлов C , поэтому node-gyp может интерпретировать расширение неожиданным образом (возможно, как исходный файл C). Изменение расширения на что-то более распространенное может помочь делу.