Компиляция x64 dll из x86 с использованием Visual Studio 2008: неразрешенные внешние символы __imp_ - PullRequest
0 голосов
/ 22 июля 2010

Я скомпилировал некоторый внешний код C ++ в dll, thirdpartycode.dll, используя Visual Studio 2008. Код обернут в extern "C".

Поскольку я кросс-компиляция, создается 64-битная DLLна моей 32-битной машине;Я использую x64 в качестве «Платформы активного решения» в «Диспетчере конфигурации».

Мой Thirdpartycode.dll успешно компилируется и связывается.Далее я хочу создать еще одну DLL-файл, содержащую код, который вызывает третийpartycode.dll: wrapper.dll.Как видно из названия, это оболочка, упрощающая определенные вызовы сложного API-интерфейса в thirdpartycode.dll.Затем я планирую вызвать wrapper.dll из программы на C #.

Однако моя проблема заключается в том, что при попытке связать мой файл wrapper.dll я получаю неразрешенные символы :-(. Для каждой функции в secondpartycode.dll,например, «func1»; я получаю неразрешенный внешний символ «__imp_func1». С помощью Dependency Walker я проверяю, что третье лицоpartpartcode.dll экспортирует «func1».Я включил / VERBOSE и вижу, что третийpartycode.lib ищется.

Если я повторяю весь этот процесс, но с использованием x86 в качестве "платформы активного решения", все работает отлично!?

Любые идеичто происходит не так?

Откуда берется префикс __imp_? Это немного сбивает с толку, так как для устранения неполадок я бы сравнил экспортированные символы из thirdpartycode.dll с помощью Dependency Walker с необходимыми символами из wrapper.obj с помощью dumpbin.

Заранее спасибо за любые ответы!

Ответы [ 2 ]

0 голосов
/ 31 мая 2011

У меня возникла похожая проблема при подключении к 64-битной dll через библиотеку-заглушку.Для моего 32-разрядного приложения, связывающегося с 32-разрядной библиотекой, кажется, что declspec (dllimport) добавляет imp к именам функций, которые он ищет, но добавляет только * imp для 64-немного дллс

Например, "function1 ()" станет "_ imp _function1" и найден для моей 32-битной версии dll, но когда я связываю 64-битную версиюdll в мое 64-битное приложение, я получаю сообщение об ошибке:

неразрешенный внешний символ __imp_function ...

Обратите внимание на одну нижнюю черту, добавленную к __imp, по сравнению с двойной чертой для 32-битной версии,Когда мне не удается связать требуемую библиотеку в 32-разрядной версии, я получаю ошибку связи:

неразрешенный внешний символ _ imp _function ...

Я могу решить проблемупросто добавив _ к имени функции в моем заголовке (т. е. _function () вместо function (). Это кладжа, но это показывает, что действительно оформление отличается для 64-битной declspec (dllimport) по сравнению с 32-bit declspec (dllimport).

Я использую Visual Studio 2010 и связываюсь с dll, созданным с помощью gcc. Я где-то читал, что 64-битные dll, созданные в Visual Studio, украшены одиночной чертой, _ imp , поэтому, возможно, проблема в том, что gcc последовательно использует двойные черты до и после, но VS ожидает, что 32-битные библиотеки dll будут оформлены иначе, чем 64-битные библиотеки.

Мне не удалось найтиописание этого отличается на MSDN Microsoft. Может ли кто-нибудь подтвердить, что существует разница между 64 и 32-разрядными в том, как declspec (dllimport) украшает имена функций в Visual Studio?

0 голосов
/ 23 июля 2010

Просто чтобы проверить, когда вы добавили thirdpartycode.lib в «Дополнительные зависимости», вы обязательно указали правильный путь к расположению библиотек?В разделе «Дополнительные каталоги библиотек» Linker-> General.

Кроме того, если проекты находятся в одном и том же решении, убедитесь, что ваш порядок сборки таков, что проект третьего стороннего кода создается перед вашим кодом?

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