Неразрешенная ссылка с подчеркиванием

Question

У меня есть проект x64 в VS2008, который должен включать старую унаследованную библиотеку, написанную на Фортране много лет назад. У меня нет исходного кода и я не могу его перекомпилировать. Имена функций в .lib начинаются с подчеркивания, но в проектах x64 используется только ссылка fastcall, которая не хочет распознавать ссылки stdcall или cdecl. Есть ли что-нибудь, что скажет сборке распознавать имена с префиксом подчеркивания?

EDIT

Все спорные вопросы, поскольку, как только я преодолел проблему с именами, он закончился сообщением мне о фатальной ошибке LNK1112: тип компьютера с модулем x86 конфликтует с типом компьютера целевой системы x64, поэтому я все равно не могу связать эту старую библиотеку.

Answer 1

Вам определенно нужен заголовочный файл. Если проблема не устранена, это означает, что определения в заголовке не определяют соглашение о вызовах.

Общий подход к обработке ошибок linke:

1. Дамп функций, используемых вашим приложением

   Корзина / символы

2. Дамп библиотеки и и длл

   свалка / экспорт свалка / экспорт

Для статических библиотек

dumpbin /symbols <libraryFileName.lib>

3. Найдите имена функций в 2 дампах (3 для библиотеки dll + import) и убедитесь, что они идентичны.

4. Любое несоответствие, которое вы обнаружите, будет указывать на вашу проблему

5. Измените ваш вызов так, чтобы он получал тот же результат, что и экспортированный материал

---

Интерпретация (некоторые из) результатов:

Функции C:

_functionName = C function, __cdecl calling convention
_functionName@12 = C function, __stdcall calling convention
@functionName@12 = C function, __fastcall calling convention

(конечно, число не обязательно должно быть 12)

C ++ функции

Они похожи? FunctionName @ Это украшенное имя. Но на свалке тоже есть неокрашенный.

Примеры:

?functionName@@$$J0YMHHPADPAUKeyVal@@@Z
(extern "C" int __clrcall functionName(int,char *,struct KeyVal *))
=> you have all the info, including the fact that this is compiled to
managed code (__clrcall)

?functionName@@YAHHPADPAUKeyVal@@@Z
(int __cdecl functionName(int,char *,struct KeyVal *))
=> normal C++ function

?functionName@className@@QAEHHPADPAUKeyVal@@@Z
(public: int __thiscall className::functionName(int,char *,struct KeyVal
*))
=> member function (because of __thiscall) of the class className

и т. Д.

---

Подсказка: я рекомендую дамп в файл, потому что результирующие дампы могут быть большими dumpbin / exports fileToDump.lib> dumpResult.txt

Бонусный совет: иногда на одной свалке вы увидите короткую без знака и в другом wchar_t Это означает, что компиляция не была сделана с теми же настройками для wchar_t (нативный тип или нет)

Answer 2

Имена с добавленными подчеркиванием используются связью C, поэтому, если ваш язык реализации - C ++ (верно?), Вы должны использовать это объявление

extern "C" {
  int foo();
  float bar();
}

Он также должен использовать __cdecl, хотя я не уверен в этом.

Answer 3

Я предполагаю, что ваша старая библиотека является 32-битной. Вы пытались скомпилировать свой проект как x86 вместо x64, чтобы увидеть, если проблема в компиляции x64? Если это так, вы можете попробовать здесь:

Вызов 32-битного кода из 64-битного процесса

Answer 4

На каком языке работает ваш проект x64? Вы должны иметь возможность указать соглашение о вызовах в своем внешнем определении для функции:

  extern int __stdcall foo();

Answer 5

Вы упомянули Фортран много лет назад, очень вероятно, что он 32-битный. Упорядочивание имен (начальное подчеркивание) - это верхушка айсберга, даже если вам удастся исправить это (проблема соглашения о вызовах), у вас все равно будет проблема вызова 64-битного из 32-битного. Ссылка Бена Роббинса выше может помочь. У нас была похожая проблема, мы подумали, что, возможно, мы сможем обернуть наши 32-битные библиотеки DLL в оболочки COM, а затем вызвать оболочку COM из 64-бит. Не знаю, сработает ли это, так как в итоге мы нашли исходный код и получили хорошую 64-битную компиляцию.