I'm getting LNK 2019 when trying to link in the OpenSSL libraries for a project I'm working on. I compiled the OpenSSL libraries and ran the test and all of them passed. I played with openssl.exe and got it to correctly create and MD5 hash. When I try to use the functions provided by the API though, it just won't recognize them. I even used dumpbin -headers on the .lib files to make sure that the ones I was using contained the correct references for the functions I was using.
I made sure to include the correct files and paths (I also included the header which isn't pictured here).
Here are the actual files and their paths
Here's the actual errors.
error LNK2019: unresolved external symbol _EVP_MD_CTX_create referenced in function _main
error LNK2019: unresolved external symbol _EVP_DigestInit_ex referenced in function _main
error LNK2019: unresolved external symbol _OpenSSL_add_all_digests
referenced in function _main error LNK2019: unresolved external symbol
_EVP_get_digestbyname referenced in function _main error LNK1120: 4 unresolved externals
How do I fix this? Did I put the files in the right place or did I forget an include? I've spent a few days trying to fix this already, this is my last resort :/
Im using Microsoft Visual Studio 2012
This can be problem with calling conventions.
Please check the project setting regarding calling convention.
OpenSSL compiles with /Gd option that means function will be of __cdecl calling convention.
You can either change your calling convention to /Gd or prefix OpenSSL function signatures which you are using with __cdecl.
I believe that this might help. This link explains how to change calling convention.
Please confirm if this can help you.
I was building for x86 when I should have been building with x64. As the x64 option did not show up in the menu, I thought it was unavailable to me. I realized that I had to add it under the project properties and now everything works fine.
Thanks for all the help.
Related
I would like to integrate Lua into my current C++ application I build with VisualStudio 2015 (x64 mode).
I grabbed a simple Lua wrapper from here, and the Lua binaries for windows x64 from here (the lua-5.1.5_Win32_dll14_lib.zip one).
Next, I added the include and library path to the project preferences. Works so far in the IDE. However, when I try to compile the code it throws 24 errors (like these first two):
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_close" referenced in function ""public: __cdecl LuaScript::~LuaScript(void)" (??1LuaScript##QEAA#XZ)".
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_gettop" referenced in function ""public: void __cdecl LuaScript::clean(void)" (?clean#LuaScript##QEAAXXZ)".
which tells me next to nothing. Seems that the linker is unable to find the library but the includes are working and the path to library is set, too. Any suggestions what I might have missed or should look into? Any hint would be appreciated!
I am trying to use SFML with Visual Studio 2013 using the tutorial on the SFML website and using their sample code (replacing main() with WinMain()) but I'm getting the linker error:
Error 1 error LNK2019: unresolved external symbol _main referenced in function _WinMain#16
I am referencing the libs:
sfml-graphics-d.lib
sfml-window-d.lib
sfml-main-d.lib
sfml-system-d.lib
and I am pointing correctly to the 'include' and 'lib' folders in my Project Properties.
I have tried using 'main()' with sfml-main-d.lib referenced and 'WinMain()' without it referenced and I still get the linker error.
Any suggestions?
Thank you for your time
Okay I seem to have solved it but don't know how. I'll do my best to explain to anyone else who is stuck:
I started a new project again with a fresh download of SFML 32-bit for VS2013.
I added sfml-main-d.lib and sfml-main.lib to my referenced libs (for debug and release respectively) and then use "int main()..." instead of "int __stdcall WinMain()" and it linked and compiled correctly.
I thought I had already tried this combination but I guess maybe not.
Thanks to anyone who took the time to read this question and to Elried for commenting.
Well i basically inherited a bunch of code that i was told to fix because it used to work a few months ago but it doesn't at the moment. The program itself seems to be riddled with linking errors and i was able to fix some of them. However I have run across a LNK2019 unresolved external _imp error where some function utilized in the main is not resolved. due to the "_imp" i am assuming that it is a problem related to importing from .dll or .lib files.
First of all i have three .lib files which i believe am importing them correctly into VS2010 and i have configured the platform to be 64x. There is also .dll files that correspond with the .lib files. The .h file that contains the declaration for these error ridden functions contain something like
ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);
unfortunately i would be guessing that the definition is defined in the .dll file which i did not write myself so i am unsure. But since this is code that worked before i believe that i am getting this error because the linker can't find the definition rather than def/decl not matching reason.
when i hover over the ILAPI it states: "ILAPI __declspec(dllimport)"
My current guess is that the program imports the .lib files and the .lib files use the .dll files to get the definition of the functions. I believe that i am importing the .lib files since the compiler no longer keeps on telling me that it can't find specific .lib files. However i am concerned that it may not be connecting the the .dll files. I am some what unsure. I have opened the .lib files and the .lib files contain the names of the functions that are giving errors. I have also used the dependency walker program to look at my DLL files and it has been giving me some of the following errors:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Based on other peoples comments i feel like i can ignore the 2nd error. But i am unsure of the first error. I am also unsure if that would be the root cause of the problem. It may or may not be.
I have also looked inside the .lib files using VS cmd and dependency walker and it seems like the names of the functions that can't be found are listed in one of the .lib and .dll.
In terms of configuration I am running on release mode x64 platform.
I have added "DevIL.lib ILU.lib ILUT.lib " library functions in the proj -> prop -> linker -> commandline. I have also added the path for linker -> general -> additional library directory. I have also tried messing with input additional dependency but it has no effect. The .lib and .dll files are put in the same directory as well. In the proj property configuration i do not mention .dll anywhere (am i supposed to? I've tried in various locations but just creates more error) I understand that there are a ton of posts regarding link 2019 error but i have not had good luck so far in my search for my particular problem. I would appreciate any suggestions, comment, or a link where i may find a clue as in to why this is occuring
here is the linker command from log:
here is the linker command from the build log itself:
Link:
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>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
// 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
Also:
#define ILAPIENTRY __stdcall
build log info when it gets close to error:
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.
Build FAILED.
Just in case i have also tried writing #define _IL_BUILD_LIBRARY but has no effect.
I'm adding an answer here to summarize a bit on the above comments, the probable root cause and finding a solution to the unresolved errors. I'll preface this by saying linkers tend to be dumb low level tools. If the symbols referenced in the object files don't match exactly with the library then the build process bails out with those unresolved errors. Therefore, the author of the dll library and clients using it will need to put in some effort to ensure the symbols agree.
Root Causes
Unresolved errors are usually caused by one of the follow:
Neither the project nor the libraries linked against implement the function for that symbol.
The libraries actually do implement the function but under a differing reference symbol.
The headers for the library aren't preprocessed or decorated correctly thereby causing #2.
The Hunt
Base on what the OP described the dll libraries linked against exposes a C API. It is unclear what calling convention is being followed by the library in question. The exported names in the dll contain plain undecorated function names suggesting a __cdecl convention. The provided corresponding headers, OTOH has a function like:
ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);
which expands into this after preprocessing:
__declspec(dllimport) void __stdcall ilDeleteImage(const ILuint Num);
From this you can conclude three possible scenarios:
The unresolved functions follow a __cdecl convention and the provided headers are wrong.
The unresolved functions follow a __stdcall convention and the exported dll names are wrong.
The functions follow __stdcall but are undecorated to look like __cdecl in the dll. This suggest that a .def file might have been used to build the dll in question.
A Sad State of Affair
Unfortunately, the function call convention followed in a win32 dll is in a confusing state of affairs. There's nothing in the language standard, C or C++, that addresses this ABI issue. See my other answer here. The toolchain vendor is free to decorate the names however they like but typcially for __cdecl functions it's plain undecorated or with a prefixed leading _ underscore.
WinAPI functions you find, like in kernel32.dll user32.dll gdi32.dll etc. are also undecorated but yet follow __stdcall. However, MSVC itself decorates __stdcall with a trailing ampersand with total bytes of the parameters(eg. ilDeleteImage#4) thus contributing to the confusion. To override how LINK decorates the functions, you have to provide a .def file that specifies the new name alias. See here for more details.
Finding the Real Convention
Assuming you don't have access to the source used to build the dll, there are two approachs I can think of to identify the real convention used.
Create a minimal test application that calls into the dll functions as if it uses __cdecl and see if it crashes and burns. This is the easier more straightforward method and you don't have to understand assembly to do it.
Second approach, you do the same but insert assembly breakpoints into your test application and run it through the debugger doing single step instructions. Make sure to choose a dll function taking at least one parameter. For example:
// pullin dll headers
// etc..
int main()
{
__asm int 3;
ilDeleteImage(0xdecafbad);
}
This will break and give control back to the debugger right before the dll function call. From here single step at the assembly level until you reach ilDeleteImage's function prologue.
; function prologue
push ebp
mov ebp, esp
; function implemention
; more opcodes here
; ...
; function epilogue
mov esp, ebp
pop ebp
ret 0x8
Check what form of ret is being used on function return. The number argument following the ret mnemonic indicates how much to increment the esp stack pointer. Any number >0 suggestes a __stdcall function. The hypothical disassembly above shows a __stdcall function freeing 8 bytes on the stack which also hints that this function takes 2 arguments.
I had this compile error while building a project using external static libraries, QDBM and PCRE:
_main.obj : error LNK2001: unresolved external symbol __imp__dpversion
_main.obj : error LNK2001: unresolved external symbol __imp__regcomp
I had correctly configured these external projects to build static libraries, but I had forgotten to define the correct preprocessor defines in my own code, which used these libraries, to enable static linking.
So when they imported the headers from QDBM and PCRE, they added a __declspec(dllimport) that shouldn't be there (for static linking), so they were trying to import symbols from DLLs that didn't exist.
I added the missing preprocessor defines to my build system, which fixed the error:
-DQDBM_STATIC -DPCRE_STATIC
Which meant adding the following lines to my CMakeLists.txt file:
# Tell QDBM not to build itself as a DLL, because we want to link statically to it.
target_compile_definitions(qdbm PUBLIC -DQDBM_STATIC)
target_compile_definitions(lib_common PUBLIC -DPCRE_STATIC)
I just tried to build Qt for WinCE7.0 using VS2008 after lots of code modification I successfully compiled main libraries.
While Compiling the QtScript library I received the following linker errors:
1>Linking...
1> Creating library ..\..\lib\QtScript4.lib and object ..\..\lib\QtScript4.exp
1>BytecodeGenerator.obj : error LNK2019: unresolved external symbol __imp__Inf referenced in function "public: static double __cdecl QTWTF::FloatHashTraits<double>::emptyValue(void)" (?emptyValue#?$FloatHashTraits#N#QTWTF##SANXZ)
1>Executable.obj : error LNK2001: unresolved external symbol __imp__Inf
1>MathObject.obj : error LNK2001: unresolved external symbol __imp__Inf
1>DateMath.obj : error LNK2019: unresolved external symbol __imp__Nan referenced in function "double __cdecl QTWTF::parseDateFromNullTerminatedCharacters(char const *,bool &,int &)" (?parseDateFromNullTerminatedCharacters#QTWTF##YANPBDAA_NAAH#Z)
1>JSValue.obj : error LNK2001: unresolved external symbol __imp__Nan
1>..\..\lib\QtScript4.dll : fatal error LNK1120: 2 unresolved externals
I have absolutely no idea which libraries I missed to link with!
Thanks
If you're using Windows, I'll assume you're building in MSVS. I often start projects WITHOUT default libs and if I happen to touch "out of reach" terriotry from another lib, I add what I need as I go along.
Fortunately, MSVS is great at helping me with this. Just turn VERBOSE compiling status and see what libs it's trying to access, then just add them:
right click the project, linker, show progress -> select VERBOSE
Another method is when I check MSDN for Microsoft functions and see the lib they are declared in and add it (since VERBOSE can be overkill on my poor output window). I don't know if Qt has a detailed reference documentation (also stating the libs) but it's worth a shot.
When all else fails, just add all libs Qt could possibly want (make sure IGNORE STANDARD LIBS is disabled) then check VERBOSE and only keep those in the list.
Assuming you have all the libraries in the project, another problem is mismatched dependencies (right click the solution, startup project -> select the one you need, [project dependencies -> map each dependency for the specified libs).
Also make sure when you import an extern the lib is defined in Linker->Input.
However, if you modified the source (either adding new functions/global or static vars or you modified function signatures), the unresolved external reference means a function/var definition has no associated body. Either implement one or add { } in the definition; so if that's the case, check the functions/vars from the error message.
I am trying to run the example code from the MATLAB Doc, but when I try to build the project in Visual Studio I get this error
fatal error C1083: Cannot open include file: 'engine.h': No such file or directory
The fact is that in the Doc I cannot find where to find the header to link it, they show the examples as if there was no need to do anything else, just do the
#include "engine.h";
Any ideas about how to solve this issue?
EDIT
I solved the first problem but now I get some errors reated to missing libs:
1>engwindemo.obj : error LNK2019: unresolved external symbol _engClose referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _mxGetClassName referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _engGetVariable referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _engOutputBuffer referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _mxDestroyArray referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _engEvalString referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _engPutVariable referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _mxGetPr referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _mxCreateDoubleMatrix_730 referenced in function _main
1>engwindemo.obj : error LNK2019: unresolved external symbol _engOpen referenced in function _main
I set the Path variable as told in the documentation, set the lib path and added some libraries and now I don't know what else can I do. I also rebooted VisualStudio in order to make the Path variable change effective.
Thanks in advance.
I finaly solved the problem. I was building a WIN32 project, while matlab is x64, so VisualStudio gives errors when you try to link 64-bit platforms. The solution is changing the Active Solution Platform to x64, inside Project Properties -> Configuration Manager.
It is well explained in the following link.
Thanks anyway for the answers, they were useful.
So, summarizing, to be able to compile and run a c++ code in VisualStudio2008 and Matlab2010 with engine.h, the following steps are required:
1.- Set Path variable in Advanced System Settings-> environment variables: C:\Program Files\MATLAB\R2010a\bin\win64 (or the path where libeng.dll is located)
2.- In project properties of VisualStudio, link in Additional Include directories of C++->General:
"C:\Program Files\MATLAB\R2010a\extern\include"
3.- In project properties, linker->general, Additional Library Directories:
"C:\Program Files\MATLAB\R2010a\extern\lib\win64\microsoft"
4.- Add the following libraries in Linker->Additional Dependencies:
libeng.lib
libmx.lib
5.- Change the Active Solution Platform to x64, in Configuration Manager as explained in the link.
Have you added the MATLAB include directory to your project's include path?
. The directory should be like "C:\Program Files\MATLAB\R2010a\extern\include"
In case you forgot, add the folder containing libmat.dll libmx.dll etc. to your path. For me that was:
C:\Program Files\MATLAB\R2012a\bin\win64
While the Jav_Rock's answer is completely correct, I want to add information about one of the points:
1.- Set Path variable in Advanced System Settings-> environment variables: C:\Program Files\MATLAB\R2010a\bin\win64 (or the path where
libeng.dll is located)
I spent three hours to understant what does it means, so I want to clarify this moment for future researchers.
You need to add the path of MATLAB Engine dll libraries to your Windows.
We can do it this way:
My Computer -> right click: Settings. Opened System window. Left bottom corner: Advanced System Settings
Advanced Tab
In the Environment variables for your user press Create... button and add this one:
Variable name: PATH
Variable value: C:\Program Files\MATLAB\R2016a\bin\win64
This path is reference on where is your libeng.dll located.
Important moment: it can require to restart VS or even restart computer.