Ну, я в основном унаследовал кучу кода, который мне сказали исправить, потому что он работал несколько месяцев назад, но сейчас не работает. Сама программа, кажется, изобилует ошибками компоновки, и я смог исправить некоторые из них. Однако я столкнулся с неразрешенной внешней ошибкой _imp LNK2019, когда некоторая функция, используемая в основном, не разрешена. из-за "_imp" я предполагаю, что это проблема, связанная с импортом из файлов .dll или .lib.
Прежде всего, у меня есть три файла .lib, которые, как мне кажется, правильно импортируются в VS2010, и я настроил платформу на 64x. Существуют также файлы .dll, соответствующие файлам .lib. Файл .h, содержащий объявление для этих функций с ошибками, содержит что-то вроде
ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);
к сожалению, я бы предположил, что определение определено в файле .dll, который я не писал сам, поэтому я не уверен. Но поскольку это код, который работал раньше, я считаю, что получаю эту ошибку, потому что компоновщик не может найти определение, а не причину, по которой def/decl не соответствует.
когда я наводил курсор на ILAPI, он говорил: «ILAPI __declspec(dllimport)». Мое текущее предположение состоит в том, что программа импортирует файлы .lib, а файлы .lib используют файлы .dll для получения определения функций. Я считаю, что импортирую файлы .lib, поскольку компилятор больше не говорит мне, что не может найти определенные файлы .lib. Однако я обеспокоен тем, что он может не подключать файлы .dll. Я что-то неуверен. Я открыл файлы .lib, и файлы .lib содержат имена функций, которые выдают ошибки. Я также использовал программу обхода зависимостей для просмотра моих DLL-файлов, и она выдавала мне некоторые из следующих ошибок:
Ошибка: по крайней мере один модуль имеет неразрешенный импорт из-за отсутствия функции экспорта в неявно зависимом модуле.
Ошибка: Найдены модули с разными типами ЦП.
Основываясь на комментариях других людей, я чувствую, что могу игнорировать 2-ю ошибку. Но я не уверен в первой ошибке. Я также не уверен, что это будет основной причиной проблемы. Это может быть, а может и не быть.
Я также просмотрел файлы .lib с помощью VS cmd и обходчика зависимостей, и кажется, что имена функций, которые невозможно найти, перечислены в одном из .lib и .dll.
Что касается конфигурации, я работаю на платформе x64 в режиме выпуска. Я добавил библиотечные функции DevIL.lib ILU.lib ILUT.lib в proj -> prop -> linker -> commandline. Я также добавил путь для компоновщика -> общий -> каталог дополнительной библиотеки. Я также пытался возиться с дополнительной зависимостью ввода, но это не дало никакого эффекта. Файлы .lib и .dll также помещаются в тот же каталог. В конфигурации свойства proj я нигде не упоминаю .dll (я должен? Я пробовал в разных местах, но просто создает больше ошибок) Я понимаю, что есть масса сообщений об ошибке link 2019, но у меня не было хорошего удачи до сих пор в моем поиске моей конкретной проблемы. Я был бы признателен за любые предложения, комментарии или ссылку, где я могу найти ключ к тому, почему это происходит.
вот команда компоновщика из лога:
вот команда компоновщика из самого журнала сборки:
Ссылка: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\link.exe/ERRORREPORT:PROMPT/OUT:"x64\Release\dff.exe"/VERBOSE/INCREMENTAL/NOLOGO/LIBPATH: C:\Users\Sub2\Desktop\dff\x64\Release/MANIFEST/ManifestFile:"x64\Release\dff.exe.intermediate.manifest"/MANIFESTUAC:"level='asInvoker' uiAccess='false'"/DEBUG/ PDB:"C:\Users\Sub2\Desktop\dff\x64\Release\dff.pdb" /SUBSYSTEM:CONSOLE/OPT:REF/OPT:ICF/TLBID:1/DYNAMICBASE/NXCOMPAT/IMPLIB:"x64\Release\ dff.lib" /MACHINE:X64 x64\Release\dff.exe.embed.manifest.res x64\Release\acquisition.obj x64\Release\azmemutil.obj x64\Release\dff.obj x64\Release\fft.obj x64 \Release\FocusMeasure.obj x64\Release\ge.obj x64\Release\stdafx.obj DevIL.lib ILU.lib ILUT.lib 1>ССЫЛКА: предупреждение LNK4075: игнорирование '/INCREMENTAL' из-за спецификации '/OPT:ICF'
// This is from Win32's <wingdi.h> and <winnt.h>
#if defined(__LCC__)
#define ILAPI __stdcall
#elif defined(_WIN32) //changed 20031221 to fix bug 840421
#ifdef IL_STATIC_LIB
#define ILAPI
#else
#ifdef _IL_BUILD_LIBRARY
#define ILAPI __declspec(dllexport)
#else
#define ILAPI __declspec(dllimport)
#endif
#endif
#elif __APPLE__
#define ILAPI extern
#else
#define ILAPI
#endif
Также:
#define ILAPIENTRY __stdcall
построить информацию журнала, когда она приближается к ошибке:
Found KERNEL32_NULL_THUNK_DATA
Referenced in kernel32.lib(KERNEL32.dll)
Loaded kernel32.lib(KERNEL32.dll)
Searching C:\Users\Sub2\Desktop\dff\x64\Release\DevIL.lib:
Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILU.lib:
Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILUT.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\MSVCRT.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\OLDNAMES.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\msvcprt.lib:
Finished searching libraries
Finished pass 1
Invoking CVTRES.EXE:
/machine:amd64
/verbose
/out:"C:\Users\Sub2\AppData\Local\Temp\lnk92ED.tmp"
/readonly
"x64\Release\dff.exe.embed.manifest.res"
Microsoft (R) Windows Resource To Object Converter Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
adding resource. type:MANIFEST, name:1, language:0x0409, flags:0x30, size:2
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluGetImageInfo referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluImageParameter referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilDeleteImages referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilSaveImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluFlipImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluScale referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilTexImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilCopyPixels referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetError referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilLoadImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilBindImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGenImages referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetInteger referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilEnable referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilOriginFunc referenced in function main
1>x64\Release\dff.exe : fatal error LNK1120: 16 unresolved externals
1>Done Building Project "C:\Users\Sub2\Desktop\dff\dff.vcxproj" (rebuild target(s)) -- FAILED.
Неудачная сборка.
На всякий случай я также пытался написать #define _IL_BUILD_LIBRARY, но безрезультатно.
ilDeleteImageдля источника, который делает вызов? - person greatwolf schedule 02.07.2013__declspec(dllimport) void __stdcall ilDeleteImage(const ILuint Num);после предварительной обработки? Это важно, потому что это напрямую влияет на то, как будет оформлена функция и, в конечном счете, на то, какой символ ищет компоновщик. - person greatwolf schedule 02.07.2013/Pдля этого . - person greatwolf schedule 02.07.2013_или@, добавленные к имени функции? - person greatwolf schedule 02.07.2013extern "C"предназначен для того, чтобы компилятор С++ не искажал имена функций, и, судя по тому, что вы описали до сих пор, рассматриваемая dll предоставляет интерфейс C. Чего я не понимаю, так это почемуilCopyPixelsне имеетextern "C"впереди после предварительной обработки. Или, может быть, весь этот раздел заключен вextern "C" {}? - person greatwolf schedule 02.07.2013extern "C" {}. - person greatwolf schedule 02.07.2013__cdecl, но на самом деле являются__stdcall? Если это так, вам может понадобиться файл.def, чтобы исправить символы для поиска во время связывания. - person greatwolf schedule 02.07.2013__cplusplusпредопределено при компиляции исходного кода С++. - person greatwolf schedule 02.07.2013.defфайлы в пакет? - person greatwolf schedule 02.07.2013__cdeclфункции в dll, но заголовок объявляет их как__stdcallсоглашение о вызовах. Это разногласие, вероятно, является причиной неразрешенной ошибки. - person greatwolf schedule 02.07.2013__cdeclили__stdcall, потому что они не взаимозаменяемы. Я полагаю, вы можете просто заставить его быть__cdecl, а затем посмотреть, не вылетит ли ваша программа после этого. Вы также можете разобрать одну из функций dll и проверить код очистки в эпилоге функции. - person greatwolf schedule 02.07.2013mov esp ebp; pop ebp. Ищите приращения кesp, которые указывают на то, что пространство стека освобождается текущей функцией, прежде чем она вернется к вызывающей стороне. Если вы видите, что это происходит, это, вероятно, означает, что это функция__stdcall. - person greatwolf schedule 02.07.2013.textкстати. - person greatwolf schedule 02.07.2013retвы видите какое-либо число после нее? Обратите внимание, что вы копаетесь в внутренностях dll нижнего уровня - смотреть на сборку непросто, и это часто сбивает с толку, если вы к этому не привыкли. Так что может быть проще просто скомпилировать, запустить его с__cdeclи посмотреть, не сработает ли он. - person greatwolf schedule 02.07.2013