Проблемы с компиляцией DLL, которая обращается к другой DLL - PullRequest
4 голосов
/ 24 марта 2009

Итак, у меня есть интересная проблема. Я работаю с проприетарным набором DLL, для которого у меня, очевидно, нет источника. Цель состоит в том, чтобы написать промежуточный dll, который группирует большую серию вызовов функций из проприетарных dll. Проблема, с которой я сталкиваюсь при компиляции с g ++, заключается в том, что я получаю ошибки для оригинальных dll по следующим направлениям: не может экспортировать libname_NULL_THUNK_DATA. Символ не найден.

Если я добавляю основной файл и просто компилирую в исполняемый файл, все работает как положено. Я использую Mingw для компиляции. Спасибо за любую помощь.

В ответ на первый ответ: Либо я не понимаю, что вы говорите, либо я не очень хорошо сформулировал свой вопрос. Я не пытаюсь явно экспортировать что-либо из моей оболочки, я просто вызываю функции из их dll. Проблема в том, что я получаю ошибки, что он не может экспортировать эти конкретные символы из DLL в мою оболочку. Проблема в том, что я даже не совсем уверен, для чего эти символы _NULL_THUNK_DATA. Я сделал поиск и прочитал где-то, что они не должны быть экспортированы, потому что они являются внутренними символами, которые использует Windows. Я попытался использовать директиву --exclude-symbols для компоновщика, но, похоже, он ничего не сделал. Я прошу прощения, если я полностью неправильно понимаю, что вы пытаетесь сказать.

Итак, я думаю, что моя проблема была связана с этим. При компиляции стандартного исполняемого файла, использующего dll, я смог включить заголовки и напрямую вызвать функции, например:

#include :3rdparty.h
int main(){
  dostuff(); // a function in the 3rdparty.dll
}

это скомпилируется и будет работать нормально. Мне просто нужно было связать библиотеки в команде g ++. При связывании с флагом -shared я получаю эти ошибки (с удаленным main, конечно). Я думаю, что это как-то связано с тем, что по умолчанию g ++ пытается импортировать все символы из dll. То, что я не понял, это то, почему это происходит в DLL против исполняемого файла. Я постараюсь сделать это с помощью GetProcAddress (). Спасибо!

Ответы [ 2 ]

2 голосов
/ 24 марта 2009

все должно быть так просто, как вы думаете.

например: Ваш код DLL должен:

void doStuff()
{
  3rdparty.login();
  3rdparty.dostuff();
  3rdparty.logoff();
};

пока что - так хорошо, что вы включили правильные заголовки .... (если они у вас есть, если нет, вам нужно импортировать библиотеку с помощью LoadLibrary (), а затем создать указатель на функцию экспортированная точка входа в dll с использованием GetProcAddress (), а затем вызов указателя этой функции)

Затем вы связываетесь со сторонней библиотекой и все. Иногда вам нужно будет обернуть определения «extern« C »», чтобы получить правильное искажение имени связи.

Поскольку вы говорите, что используете g ++, вы не можете запутаться с __declspec (dllimport), который является расширением MS VC.

0 голосов
/ 24 марта 2009

«Компиляция» говорит мне, что вы подходите к этому не с того конца. Ваша DLL не должна экспортировать свои собственные функции-оболочки, а должна напрямую ссылаться на экспорт из других DLL.

например. в файле Windows Kernel32.DEF существует следующая пересылка:

   EXPORTS
   ...
   HeapAlloc = NTDLL.RtlAllocHeap

Нет кода для функции HeapAlloc.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...